Um custom destination é um canal que aponta para um URL que você controla, em vez de para uma rede social. A Ocoya faz POST de cada publicação agendada para esse URL em JSON, e o seu código decide o que significa publicar — um artigo no seu CMS, uma linha numa base de dados, uma mensagem numa fila.
Esta página é o contrato que o seu endpoint tem de satisfazer. Para o corpo completo do pedido, veja Custom (webhook) na help center.
Os custom destinations são ligados na app da Ocoya — Channels → Connect channel → Custom. Não existe nenhum endpoint REST ou MCP que ligue um, por isso esta página descreve o endpoint que você escreve, não um que você chama.
O que a Ocoya envia
Um POST com um corpo JSON e Content-Type: application/json, mais quaisquer headers que você tenha configurado no canal.
{
"event": "post.published",
"post": {
"id": "clx…",
"title": "…",
"caption": "…",
"image": "https://…",
"options": { "slug": "…" }
}
}O que o seu endpoint tem de responder
Três coisas, todas obrigatórias. Uma publicação que falhe alguma delas é registada como falhada.
1. Um status 2xx
Qualquer outro é registado como uma publicação falhada, e o status e o corpo da resposta são mostrados na publicação para você poder ver o que o seu endpoint disse.
2. Um id
O seu próprio identificador para o que acabou de criar — um id de linha na base de dados, um id de documento no CMS, o que quer que você usasse para procurar o registo. A Ocoya guarda-o e envia-o de volta para o seu URL de eliminação, por isso é por isto que você apaga.
3. Um url
O endereço para onde publicou. Torna-se o link View post da publicação na Ocoya.
{
"id": "9f2c1a",
"url": "https://yourblog.com/post"
}| Field | Type | Required | What it does |
|---|---|---|---|
id | string | Yes | O seu identificador para o conteúdo criado. Enviado de volta como id num delete. |
url | string | Yes | O endereço publicado. Torna-se o link View post da publicação. |
Estas são as únicas duas keys lidas da resposta, e ambas as grafias são exatas. permalink era aceite como sinónimo de url em versões anteriores e já não é.
Ambas são lidas apenas desta resposta. Não há callback para as enviar mais tarde, por isso um endpoint que coloca o trabalho em fila tem de saber o seu id e endereço antes de responder, e não depois de o trabalho acabar.
Se o seu endpoint responder 2xx sem elas, a Ocoya regista a publicação como falhada e diz isso na publicação. É bem possível que o conteúdo já exista no seu destino nessa altura — a mensagem diz isso mesmo, porque voltar a publicar às cegas criaria uma segunda cópia.
Timing
O seu endpoint tem 30 segundos para responder. Confirme o pedido primeiro e faça o trabalho demorado depois, em vez do contrário.
Um redirect é seguido em vez de tratado como falha, desde que o endereço para onde aponta passe as mesmas verificações que o original. O método é mantido, por isso o seu endpoint continua a receber um POST com o corpo. O limite é de três saltos.
Eliminar
Se o canal tiver um URL de eliminação, ao eliminar uma publicação na Ocoya é enviado um pedido post.deleted para lá com o id que você devolveu quando publicou:
{
"event": "post.deleted",
"id": "9f2c1a",
"post": { … }
}id está ao nível de topo e sozinho — o identificador que você emitiu, sem nada para fazer parse e sem wrapper para atravessar. O url que devolveu não é enviado de volta: um endpoint que apaga pelo seu próprio id não tem utilidade para um endereço que já conhece.
Responda com qualquer 2xx. Se a publicação já não existir do seu lado, 404 ou 410 é registado como já eliminada e não como falha. A publicação é eliminada na Ocoya de qualquer forma.
Relacionado
Custom (webhook)
O payload completo, headers, limites e problemas comuns.