Entregas

Toda tentativa de entregar um evento no seu endpoint vira uma linha aqui. Serve para três perguntas: chegou? o que o meu endpoint respondeu? e como reenvio o que falhou, sem abrir o painel.

Listar (link para esta seção)

GET/public/v1/deliveries
ParâmetroO que é
statuspending, delivering, delivered ou failed. Sem ele, vêm todas.
limitAté 200 por página. Padrão 50.
before_idCursor: traz o que é anterior a esse id. Use o next_before_id da resposta.
curl
curl "https://api.patrociniotech.com/public/v1/deliveries?status=failed&limit=100" \
  -H "Authorization: Bearer ptk_live_..."
resposta
{
  "success": true,
  "data": {
    "deliveries": [
      {
        "id": 1841,
        "event": "message.status",
        "status": "failed",
        "attempts": 7,
        "last_status": 502,
        "next_attempt_at": null,
        "delivered_at": null,
        "created_at": "2026-07-29T18:00:00Z",
        "message_id": "wamid.HBgNNTUyMT...",
        "message_status": "delivered",
        "recipient": "5521999999999",
        "client_ref": "pedido-8421"
      }
    ],
    "next_before_id": 1841
  }
}
Paginação por cursor, não por página. Repita a chamada passando before_id igual ao next_before_id que veio, até ele vir nulo. Cursor custa o mesmo na primeira e na milésima página; offset faria o banco ler e jogar fora tudo que veio antes.

Ver uma entrega (link para esta seção)

GET/public/v1/deliveries/{id}

Igual à listagem, mais o campo last_error: o corpo do que o SEU endpoint respondeu, guardado mesmo quando ele aceitou.

É o campo que responde "o webhook chegou mas nada aconteceu, por quê?". Um 200 pode dizer no corpo que não aplicou (id desconhecido, evento ignorado, payload torto). Sem olhar isso, o problema fica invisível dos dois lados.
curl
curl "https://api.patrociniotech.com/public/v1/deliveries/1841" \
  -H "Authorization: Bearer ptk_live_..."

Reenviar (link para esta seção)

POST/public/v1/deliveries/{id}/retry

Devolve a entrega para a fila. Vale para failed (esgotou as tentativas) e para delivered (reprocessar do seu lado). O corpo é assinado de novo no disparo, com o timestamp do momento, então uma entrega reenviada horas depois não esbarra na janela de replay do seu endpoint.

curl
curl -X POST "https://api.patrociniotech.com/public/v1/deliveries/1841/retry" \
  -H "Authorization: Bearer ptk_live_..."
POST/public/v1/deliveries/retry-failed

Reenvia tudo que esgotou as tentativas, de uma vez. É o caso comum depois de consertar o endpoint. Devolve requeued com quantas voltaram para a fila.

curl
curl -X POST "https://api.patrociniotech.com/public/v1/deliveries/retry-failed" \
  -H "Authorization: Bearer ptk_live_..."

Rotina sugerida (link para esta seção)

Uma varredura de hora em hora resolve o caso real: o seu endpoint caiu de madrugada, a fila acumulou, alguém consertou de manhã.

Node.js
async function varrerFalhas() {
  const r = await fetch(`https://api.patrociniotech.com/public/v1/deliveries?status=failed&limit=200`, {
    headers: { Authorization: `Bearer ${process.env.PT_API_KEY}` },
  });
  const { data } = await r.json();
  if (!data.deliveries.length) return;

  // Avise o time ANTES de reenviar: se o endpoint ainda está quebrado, reenviar só
  // enche a fila de novo e esconde o problema.
  await alertar(`${data.deliveries.length} entregas de webhook falharam`);

  await fetch(`https://api.patrociniotech.com/public/v1/deliveries/retry-failed`, {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.PT_API_KEY}` },
  });
}

Situações (link para esta seção)

statusO que significa
pendingNa fila, esperando a próxima tentativa.
deliveringUm worker está entregando agora.
deliveredSeu endpoint respondeu 2xx. Olhe last_error para ver o que ele disse.
failedEsgotou as tentativas (cerca de 31h). Fica guardada esperando reenvio.