Una custom destination è un canale che punta a un URL di tua proprietà invece che a un social network. Ocoya fa POST di ogni post programmato su quell’URL in formato JSON, e il tuo codice decide cosa significhi “pubblicare” — un articolo nel tuo CMS, una riga in un database, un messaggio in una coda.
Questa pagina è il contratto che il tuo endpoint deve rispettare. Per il body completo della richiesta, vedi Custom (webhook) nel centro assistenza.
Le custom destinations si collegano nell’app Ocoya — Channels → Connect channel → Custom. Non esiste un endpoint REST o MCP per collegarle, quindi questa pagina descrive l’endpoint che scrivi tu, non uno che chiami.
What Ocoya sends
Un POST con un body JSON e Content-Type: application/json, più qualsiasi header tu abbia configurato sul canale.
{
"event": "post.published",
"post": {
"id": "clx…",
"title": "…",
"caption": "…",
"image": "https://…",
"options": { "slug": "…" }
}
}What your endpoint must reply
Tre cose, tutte obbligatorie. Una pubblicazione che ne manca anche solo una viene registrata come non riuscita.
1. Uno status 2xx
Qualsiasi altro valore viene registrato come una pubblicazione non riuscita, e lo status e il body della risposta vengono mostrati sul post così puoi vedere cosa ha risposto il tuo endpoint.
2. Un id
Il tuo identificatore per ciò che hai appena creato — un id di riga nel database, un id di documento nel CMS, qualunque cosa useresti per cercare il record. Ocoya lo memorizza e lo rimanda al tuo URL di delete, quindi è con questo che effettui l’eliminazione.
3. Un url
L’indirizzo a cui hai pubblicato. Diventa il link View post del post in Ocoya.
{
"id": "9f2c1a",
"url": "https://yourblog.com/post"
}| Field | Type | Required | What it does |
|---|---|---|---|
id | string | Yes | Il tuo identificatore per il contenuto creato. Inviato di nuovo come id su una delete. |
url | string | Yes | L’indirizzo pubblicato. Diventa il link View post del post. |
Queste sono le uniche due chiavi lette dalla risposta, e l’ortografia deve essere esatta in entrambi i casi. permalink era accettato come sinonimo di url nelle versioni precedenti e non lo è più.
Entrambe vengono lette solo da questa risposta. Non c’è nessun callback per inviarle in un secondo momento, quindi un endpoint che mette il lavoro in coda deve conoscere il suo id e il suo address prima di rispondere, non dopo che il lavoro è finito.
Se il tuo endpoint risponde con 2xx senza questi valori, Ocoya registra la pubblicazione come non riuscita e lo indica sul post. È molto probabile che in quel momento il contenuto esista comunque nella tua destinazione — il messaggio lo dice chiaramente, perché ripubblicare alla cieca creerebbe una seconda copia.
Timing
Il tuo endpoint ha 30 secondi per rispondere. Conferma la richiesta per prima cosa ed esegui il lavoro lento dopo, non il contrario.
Un redirect viene seguito invece che considerato un errore, purché l’indirizzo a cui punta superi gli stessi controlli dell’originale. Il metodo viene mantenuto, quindi il tuo endpoint riceve comunque un POST con il body. Il limite è di tre hop.
Deleting
Se il canale ha un delete URL, l’eliminazione di un post in Ocoya invia una richiesta post.deleted a quell’URL contenente l’id che hai restituito al momento della pubblicazione:
{
"event": "post.deleted",
"id": "9f2c1a",
"post": { … }
}id è al livello più alto e da solo — l’identificatore che hai emesso, senza nulla da fare il parse e senza wrapper da attraversare. L’url che hai restituito non viene inviato di nuovo: un endpoint che elimina tramite il proprio id non ha bisogno di un address che già conosce.
Rispondi con qualsiasi 2xx. Se il post sul tuo lato è già stato eliminato, 404 o 410 vengono registrati come già eliminato invece che come errore. Il post viene eliminato in Ocoya in entrambi i casi.
Related
Custom (webhook)
Il payload completo, gli header, i limiti e i problemi più comuni.