Redespacho manual
Toda entrega de webhook fica registrada por 60 dias no painel da INFI. Se o seu endpoint estava fora no momento da entrega original, ou se você precisa reprocessar um evento, dispare uma nova tentativa pelo painel.
Onde reenviar
Há dois caminhos:
1. Pela transação (timeline)
No painel: Pagamentos → clique em uma transação → drawer abre.
A seção “Webhooks enviados” mostra cada entrega que foi disparada por aquele evento, com:
- Status (sucesso, falha, pendente).
- HTTP status da última tentativa.
- Quantidade de tentativas (incluindo manuais).
- Data/hora da última tentativa.
- Botão reenviar ao lado de cada linha.
2. Pela página dedicada (lista global)
No painel: Webhooks → Histórico de entregas.
Lista paginada de todas as entregas dos últimos 60 dias. Filtros por:
- Status: sucesso, falha, pendente.
- transactionId: cole o ID e busque.
Cada linha tem o botão detalhes que abre um drawer lateral com:
- Payload exato que foi enviado (JSON formatado).
- Timeline completa de tentativas (com
manual: truenas tentativas disparadas por você). - Botão Reenviar webhook que dispara nova tentativa.
Comportamento do reenvio
Quando você reenvia uma entrega:
| Campo | O que acontece |
|---|---|
eventId | Preservado — mesmo evt_xxx da entrega original. Se você implementa dedupe por X-Infi-Event-Id, a tentativa de reenvio é tratada como duplicada (correto). |
transactionId, status, event | Idênticos à entrega original. |
timestamp | Regenerado para o momento do reenvio. Clientes que rejeitam timestamps antigos (replay-protection) aceitam normalmente. |
X-Infi-Signature | Recalculado com o novo timestamp + body. Sua validação HMAC funciona idêntico ao primeiro envio. |
| URL alvo | A mesma URL configurada na entrega original. Se a URL foi removida desde então, o reenvio falha. |
Use X-Infi-Event-Id (ou eventId no body) como chave de dedupe. Reenviar 5 vezes a mesma entrega resulta em 1 evento processado no seu lado, com 4 retries idempotentes. Veja Retentativa.
Limites
- 10 reenvios por hora por conta. Limite duro pra evitar loops em integração com bug.
- Apenas entregas dos últimos 60 dias podem ser reenviadas (TTL do histórico).
- Reenvio só dispara para a URL original da entrega. Pra mandar pra outra URL, edite seu webhook em Webhooks → Configuração e o próximo evento vai pra ela (a entrega original continua no histórico).
Casos de uso
- Endpoint fora do ar: depois de subir de volta, abra o histórico filtrado por
failede reenvie em ordem. - Bug no processamento: corrigiu o handler, reabra a transação e reenvie pra reprocessar.
- Validação manual: quer ver o payload exato que chegou? Abra os detalhes da entrega — o JSON aparece formatado na tela.
- Migração de plataforma: configurou novo endpoint, valide com algumas entregas reenviadas antes de cortar.
Resposta da operação
A interface confirma cada reenvio:
- ✅
Reenviado (HTTP 200)— sucesso, seu endpoint respondeu 2xx. - ❌
Falhou (HTTP 500)— endpoint respondeu erro. Tente novamente após corrigir. - ❌
Falhou (erro de rede)— timeout, DNS, etc. Verifique a URL. - ❌
Limite de reenvios atingido— passou de 10/h. Aguarde.
A nova tentativa é registrada no histórico com manual: true na linha correspondente — você consegue distinguir entregas manuais das automáticas posteriormente.