Destinos personalizados

Un custom destination es un canal que apunta a una URL tuya en lugar de a una red social. Ocoya hace POST de cada publicación programada en esa URL como JSON, y tu código decide qué significa publicar: un artículo en tu CMS, una fila en una base de datos, un mensaje en una cola.

Esta página es el contrato que tu endpoint tiene que cumplir. Para ver el cuerpo completo de la petición, consulta Custom (webhook) en el centro de ayuda.

​

What Ocoya sends

Un POST con un cuerpo JSON y Content-Type: application/json, más cualquier cabecera que hayas configurado en el canal.

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

​

What your endpoint must reply

Tres cosas, todas obligatorias. Una publicación que no tenga cualquiera de ellas se registra como fallida.

​

1. Un estado 2xx

Cualquier otro se registra como una publicación fallida, y el estado y el cuerpo de la respuesta se muestran en la publicación para que puedas ver qué dijo tu endpoint.

​

2. Un id

Tu propio identificador para lo que acabas de crear: un id de fila en base de datos, un id de documento en el CMS, lo que uses para buscar el registro. Ocoya lo guarda y lo envía de vuelta a tu URL de borrado, así que esto es por lo que borras.

​

3. Una url

La dirección a la que has publicado. Se convierte en el enlace View post de la publicación en Ocoya.

{
  "id": "9f2c1a",
  "url": "https://yourblog.com/post"
}

Si tu endpoint responde 2xx sin ellas, Ocoya registra la publicación como fallida y lo indica en la publicación. Es muy posible que el contenido ya exista en tu destino en ese momento: el mensaje lo explica, porque republicar a ciegas crearía una segunda copia.

​

Timing

Tu endpoint tiene 30 seconds para responder. Reconoce la petición primero y haz el trabajo lento después, no al revés.

Una redirección se sigue en lugar de tratarse como un fallo, siempre que la dirección a la que apunte pase las mismas comprobaciones que la original. El método se mantiene, así que tu endpoint sigue recibiendo un POST con el cuerpo. El límite son tres saltos.

​

Deleting

Si el canal tiene una URL de borrado, al borrar una publicación en Ocoya se envía allí una petición post.deleted con el id que devolviste cuando se publicó:

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

id está en el nivel superior y por sí solo: el identificador que emitiste, sin nada que parsear ni envoltorios que atravesar. La url que devolviste no se envía de vuelta: un endpoint que borra por su propio id no tiene utilidad para una dirección que ya conoce.

Responde con cualquier 2xx. Si la publicación ya no existe en tu lado, un 404 o 410 se registra como ya borrada en lugar de como un fallo. La publicación se borra en Ocoya en cualquier caso.

​

Related