Retry e depuração de webhooks
Retry reenvia webhooks que falharam — o log mostra o histórico de tentativas e erros.
Onde acessar
Plataforma > Configurações > Webhooks > [webhook] > Log de enviosComo funciona o retry
Quando um webhook falha (resposta diferente de 200 ou timeout), a evob tenta reenviar automaticamente com intervalos crescentes:
| Tentativa | Intervalo após a anterior | |---|---| | 1ª (original) | Imediato | | 2ª | 5 minutos | | 3ª | 30 minutos | | 4ª | 2 horas | | 5ª | 12 horas | | 6ª | 24 horas |
Após a 6ª tentativa sem sucesso, o evento é marcado como falha permanente e não é reenvido automaticamente. Você pode acionar um reenvio manual pelo log.
Log de envios
O log registra cada tentativa de envio com:
| Campo | Descrição | |---|---| | Data/hora | Quando o disparo ocorreu | | Evento | Tipo do evento (`purchase.completed`, etc.) | | Status HTTP | Código de resposta do receptor (200, 404, 500, timeout) | | Tempo de resposta | Quantos ms o receptor demorou para responder | | Payload | Corpo da requisição enviada | | Resposta | Corpo da resposta recebida (quando disponível) |
Interpretar os status de erro
| Status | O que significa | Onde investigar | |---|---|---| | `200` | Sucesso | — | | `404` | URL não existe mais | Atualizar a URL do webhook | | `500` | Erro interno no receptor | Logs do servidor receptor | | `timeout` | Receptor demorou mais de 5s | Otimizar processamento no receptor | | `connection_refused` | URL inacessível | Verificar se o servidor está online | | `ssl_error` | Certificado SSL inválido | Renovar certificado da URL receptora |
Reenviar manualmente
Se um evento ficou em falha permanente e precisa ser reprocessado:
- Acesse Webhooks > [webhook] > Log de envios
- Localize o evento com falha
- Clique em Reenviar
- Acompanhe se o novo envio resultou em 200
Boas práticas
✅ Faça
- Monitore o log de webhooks semanalmente — falhas acumuladas indicam problema no receptor que pode estar afetando a sincronização de dados há dias sem que você perceba
- Configure alerta de falha no receptor (Zapier, Make) para receber notificação quando um cenário falhar — não dependa só do log da evob
- Implemente idempotência no receptor usando o `event_id` — em caso de retry, o receptor pode receber o mesmo evento duas vezes; idempotência garante que apenas uma execução aconteça
❌ Não faça
- Deixar webhooks em falha acumulando sem investigar — falhas permanentes significam eventos perdidos; dados no CRM ou automação ficam desatualizados
- Usar o reenvio manual como solução definitiva para falhas recorrentes — reenvio manual resolve o sintoma; a causa (URL fora do ar, receptor com bug) precisa ser corrigida
- Processar o payload de forma síncrona e demorada — se o processamento leva mais de 5s, o webhook retorna timeout e o retry é acionado; sempre retorne 200 imediatamente e processe em background
Erros comuns
"Todos os webhooks estão falhando com timeout"
O servidor receptor está sobrecarregado ou lento. Verifique a saúde do servidor. Como solução imediata, implemente retorno imediato de 200 com processamento assíncrono (fila).
"O evento foi reenviado manualmente mas falhou novamente"
O problema persiste no receptor. Verifique os logs do receptor para identificar a causa raiz antes de tentar novamente. Reenvios sem correção da causa continuarão falhando.
"O log mostra 200 mas o receptor diz que não recebeu"
O receptor retornou 200 mas pode ter processado o evento sem executar a ação esperada (ex: Zapier retorna 200 mesmo quando o cenário tem erro interno). Verifique os logs do receptor, não apenas o status HTTP.
"Quantos eventos posso ter em falha permanente ao mesmo tempo?"
Não há limite, mas eventos em falha permanente representam dados perdidos. Se a fila de falhas for grande, revise a saúde do receptor antes de acionar reenváios em massa.
Próximos passos
- 📖 Webhooks — conceito e funcionamento
- 📖 Configurar e testar um webhook
- 📖 Segurança e autenticação de webhooks (HMAC)
Foi útil este artigo? 👍 👎 Falar com CS (em produção) · Pergunte ao Vob 🤖 (em produção) Última atualização: 2026-05-07