Skip to main content
POST
/
api
/
webhook-events
/
{id}
/
retry
Reenviar Evento de Webhook
curl --request POST \
  --url https://garu.com.br/api/webhook-events/{id}/retry \
  --header 'Authorization: Bearer <token>'

Documentation Index

Fetch the complete documentation index at: https://docs.garu.com.br/llms.txt

Use this file to discover all available pages before exploring further.

​
Visão Geral

Reseta o evento para pending, zera o contador de tentativas falhas e dispara a entrega imediatamente. Funciona em qualquer status (success, failed, pending). Disponível a partir da v0.10.3. Aceita chave de API (sk_test_… / sk_live_…) ou JWT do dashboard.
A partir da v0.11.0, prefira POST /webhook-events/:id/resend./retry muta o evento original — perde o histórico de tentativas e respostas — e manda o mesmo Idempotency-Key (payload.id) da entrega original, o que pode causar drop silencioso em receivers que deduplicam por header. /resend clona, preserva o original e usa Idempotency-Key: resend_<id>, sinalizando ao receiver que é entrega nova. Veja o guia Reenviar webhook para a comparação completa./retry segue funcionando para compatibilidade com automações existentes; ele não vai ser removido sem aviso.
Rate limit: 20 requisições por minuto por IP. Para reprocessar lotes maiores, dê espaço entre as chamadas (≥ 3s entre retries) ou processe em batches de 20/min.

​
Exemplo de Requisição

curl -X POST https://garu.com.br/api/webhook-events/12345/retry \
  -H "Authorization: Bearer sk_test_sua_chave"

​
Parâmetros de Path

​
id
number
required
ID numérico do evento a reenviar.
Sem corpo de requisição.

​
Resposta

Retorna o WebhookEvent atualizado, já em pending: 
{
  "id": 12345,
  "endpointId": 7,
  "eventType": "transaction.payment.succeeded",
  "status": "pending",
  "attempts": 0,
  "lastResponseStatus": null,
  "createdAt": "2026-05-18T14:22:11Z",
  "deliveredAt": null,
  "payload": {
    "id": "evt_1a2b3c",
    "type": "transaction.payment.succeeded",
    "data": { "object": { "id": 999, "value": 49.9 } }
  }
}

​
Erros

StatusCaso
404Evento não existe ou não pertence ao seller chamando
429Rate limit excedido (mais de 20 retries/min do mesmo IP)

​
O que o reenvio faz

  1. Reseta o status para pending e zera tentativas falhas.
  2. Reenvia o mesmo payload — o id do evento (evt_…) e o conteúdo do payload são preservados. Seu receiver recebe exatamente o que receberia na primeira tentativa.
  3. Aplica a retry policy padrão caso a entrega falhe de novo (1min, 5min, 30min, 2h, 8h, 16h até failed permanente).
Como o id do evento (evt_…) é o mesmo, sua lógica de idempotência no receiver deve tratar o reenvio como duplicata — é exatamente o que ela deveria fazer com qualquer redelivery automática da Garu.

​
SDK e MCP

  • Node SDK: garu.webhookEvents.retry(id) — disponível a partir do @garuhq/node 0.11.0.
  • CLI: garu webhooks events retry <id> — disponível a partir do @garuhq/cli 0.4.0.
  • MCP: ferramenta retry_webhook_event — disponível a partir do @garuhq/mcp 0.11.0.
Veja o guia Reenviar webhook para o fluxo completo (listar → escolher → reenviar) nas quatro superfícies.