A custom destination to kanał, który wskazuje na URL należący do ciebie zamiast na sieć społecznościową. Ocoya wysyła do niego każdy zaplanowany post metodą POST w formacie JSON, a twój kod decyduje, co znaczy opublikowanie — artykuł w twoim CMS-ie, wiersz w bazie danych, wiadomość w kolejce.

Ta strona opisuje kontrakt, który twój endpoint musi spełnić. Pełne body żądania znajdziesz w artykule Custom (webhook) w centrum pomocy.

Custom destinations podłączasz w aplikacji Ocoya — Channels → Connect channel → Custom. Nie ma endpointu REST ani MCP, który je podłącza, więc ta strona opisuje endpoint, który ty piszesz, a nie taki, który wywołujesz.

What Ocoya sends

POST z body w formacie JSON i nagłówkiem Content-Type: application/json, plus wszystkie nagłówki, które skonfigurowałeś na kanale.

{
  "event": "post.published",
  "post": {
    "id": "clx…",
    "title": "…",
    "caption": "…",
    "image": "https://…",
    "options": { "slug": "…" }
  }
}

What your endpoint must reply

Trzy rzeczy, wszystkie wymagane. Publikacja bez którejkolwiek z nich jest zapisywana jako nieudana.

1. A 2xx status

Każdy inny status jest zapisywany jako nieudana publikacja, a kod statusu i body odpowiedzi są wyświetlane przy poście, żebyś mógł zobaczyć, co odpowiedział twój endpoint.

2. An id

Twój własny identyfikator tego, co właśnie utworzyłeś — id wiersza w bazie, id dokumentu CMS, cokolwiek, po czym odszukujesz ten rekord. Ocoya zapisuje go i odsyła go potem do twojego adresu usuwania, więc po tym właśnie usuwasz.

3. A url

Adres, pod którym opublikowałeś treść. Staje się on linkiem View post tego posta w Ocoya.

{
  "id": "9f2c1a",
  "url": "https://yourblog.com/post"
}
FieldTypeRequiredWhat it does
idstringYesTwój identyfikator utworzonej treści. Odsyłany z powrotem jako id przy usuwaniu.
urlstringYesOpublikowany adres. Staje się linkiem View post przy poście.

To są jedyne dwa klucze odczytywane z odpowiedzi i obie pisownie muszą być dokładnie takie. permalink był akceptowany jako synonim url we wcześniejszych wersjach i już nim nie jest.

Oba są odczytywane tylko z tej odpowiedzi. Nie ma oddzielnego callbacku, żeby dosłać je później, więc endpoint, który wrzuca pracę do kolejki, musi znać swoje id i adres, zanim odpowie, a nie dopiero po zakończeniu pracy.

Jeśli twój endpoint odpowie 2xx bez nich, Ocoya zapisze publikację jako nieudaną i pokaże taką informację przy poście. Treść może w tym momencie jak najbardziej istnieć po twojej stronie — komunikat to zaznacza, bo ponowna publikacja w ciemno utworzyłaby drugą kopię.

Timing

Twój endpoint ma 30 sekund na odpowiedź. Najpierw potwierdź żądanie, a dopiero potem wykonuj wolną pracę, a nie odwrotnie.

Przekierowanie jest śledzone, a nie traktowane jako błąd, o ile adres, na który wskazuje, przechodzi te same sprawdzenia co oryginał. Metoda jest zachowana, więc twój endpoint nadal dostaje POST z body. Limit to trzy przeskoki.

Deleting

Jeśli kanał ma adres URL do usuwania, usunięcie posta w Ocoya wyśle tam żądanie post.deleted zawierające id, które zwróciłeś przy publikacji:

{
  "event": "post.deleted",
  "id": "9f2c1a",
  "post": { … }
}

id jest w top-level i samodzielnie — to identyfikator, który wydałeś, bez niczego do parsowania i bez dodatkowej otoczki, przez którą trzeba się przebijać. Zwrócony wcześniej url nie jest odsyłany z powrotem: endpoint usuwający po swoim id nie ma pożytku z adresu, który już zna.

Odpowiedz dowolnym 2xx. Jeśli posta po twojej stronie już nie ma, 404 lub 410 są zapisywane jako już usunięty, a nie jako błąd. Post w Ocoya jest usuwany w obu przypadkach.

Custom (webhook)

Pełne payloady, nagłówki, limity i typowe problemy.