Enviar una publicación

POST /api/v1/posts/{id}/publish envía una publicación guardada, normalmente un borrador creado con draft: true o posts[]. Se compromete con hora de entrega ahora y se pone en cola; la respuesta es un 202 con la publicación, y nada espera a la plataforma. Consulta GET /api/v1/posts/{id} hasta que status sea published o failed. Necesita el permiso publish. Envía una Idempotency-Key: una petición repetida no debe enviar la publicación dos veces.

curl -X POST https://antwork.io/api/v1/posts/pQ7x.../publish \
  -H "Authorization: Bearer $ANTWORK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{}'

{
  "object": "post",
  "id": "pQ7x...",
  "status": "scheduled",
  "scheduledFor": "2026-11-05T10:00:00.000Z",
  "readiness": { "characterCount": 112, "characterLimit": 280, "overLimit": false,
                 "mediaRequired": false, "settingsRequired": false, "publishBlocker": null },
  "editUrl": "https://antwork.io/workspace/ws_.../compose?postId=pQ7x...",
  "retried": false,
  ...
}

Una publicación cuyo envío falló se reintenta: se borra el error de la plataforma y se pone en cola para dentro de un minuto, con retried: true. Lo mismo que hace la herramienta MCP publish_post con una publicación fallida.

POST /api/v1/posts/{id}/schedule con {"scheduledFor": "..."} (ISO 8601, en el futuro, como mucho 30 días después) programa una publicación guardada con las mismas comprobaciones; una publicación programada se mueve a la nueva hora. 202, y la publicación tal como queda. Necesita publish.

curl -X POST https://antwork.io/api/v1/posts/pQ7x.../schedule \
  -H "Authorization: Bearer $ANTWORK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "scheduledFor": "2026-11-05T10:00:00Z"
  }'

POST /api/v1/posts/{id}/unschedule devuelve una publicación programada a borrador y cancela su publicación en cola, igual que PATCH /api/v1/posts/{id} con status: "draft". Responde 200 con la publicación al momento, y unscheduled: false si no estaba programada. Basta con write, porque solo saca trabajo de la cola.

Los motivos son los mismos que POST /api/v1/posts da por destino. Una publicación que incumple una regla de la plataforma es un 400 (text_too_long, media_required, pinterest_board_required…); corrígela con PATCH /api/v1/posts/{id} o en su editUrl. Cuando tu plan o la cuenta no tiene hueco, es un 409 (quota_exceeded, daily_cap_reached, schedule_queue_full, duplicate_post, posting_too_close). Una publicación ya publicada es un 409 post_already_published. En ninguno de estos casos se pone nada en cola.

{
  "error": {
    "type": "invalid_request_error",
    "code": "daily_cap_reached",
    "message": "This X account has reached its daily cap ..."
  }
}

POST /api/v1/campaigns/{id}/publish envía todas las publicaciones de una campaña (el campaignId que devuelve una creación), cada una por su cuenta: una rechazada no frena a las demás, y una fallida se reintenta. Como mucho 10 publicaciones por campaña. La respuesta es el lote de la creación: un post_result por publicación, 202 si se aceptó alguna y un 400 con el primer motivo si no se aceptó ninguna. Consulta cada publicación.

curl -X POST https://antwork.io/api/v1/campaigns/camp-1a2b3c4d5e6f/publish \
  -H "Authorization: Bearer $ANTWORK_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{}'

{
  "object": "post_batch",
  "campaignId": "camp-1a2b3c4d5e6f",
  "posts": [
    { "object": "post_result", "id": "pQ7x...", "platform": "linkedin", "status": "accepted", "reason": null, ... },
    { "object": "post_result", "id": "pR2k...", "platform": "x", "status": "rejected", "reason": "text_too_long", ... }
  ]
}

POST /api/v1/campaigns/{id}/schedule con {"scheduledFor": "..."} las programa todas a la misma hora. Una campaña que no es tuya responde 404 campaign_not_found.