- Webhook = evento “empurra” para você; polling = você “puxa” em intervalos
- Webhook tende a ser mais rápido e econômico em execuções, mas exige endpoint estável e segurança
- Polling é mais simples de operar em redes restritas, mas pode gerar custo/limites e atrasos
- Quase todo problema de webhook se resolve com: validação, filas/retry e idempotência
- O modelo híbrido (webhook + reconciliação) reduz perdas e duplicidades
1) Comece pela pergunta certa: o que é “perder” para você?
Liste o evento crítico (ex.: pagamento aprovado, pedido criado, lead recebido) e qual a tolerância a atraso e duplicidade. Se atraso de minutos quebra o processo, webhook costuma ser o default. Se o risco maior é “não registrar tudo”, você vai precisar de reconciliação (polling ou consulta periódica), mesmo usando webhook.
2) Verifique se a fonte tem webhooks bons (de verdade)
Nem todo “webhook disponível” é confiável: alguns não reentregam em falha, outros não incluem ID único do evento, e vários não têm assinatura. Se o provedor não oferece tentativa de reentrega ou um identificador consistente, trate o webhook só como sinal e faça polling para confirmar.
3) Avalie infraestrutura e rede (NAT, firewall, TLS, URL pública)
Webhook exige um endpoint público com HTTPS estável. Em self-hosted, quedas de VPS, DNS e certificados viram incidentes. Se você não consegue garantir disponibilidade/observabilidade, polling pode ser menos frágil — ou você usa webhook, mas com fila e reprocessamento.
4) Compare custo operacional: execuções e limites (não só “preço do plano”)
Polling consome execuções mesmo quando nada muda. Webhook tende a executar só quando há evento. Se sua ferramenta cobra por operação/tarefa, polling agressivo pode ficar caro. Se você não tem o número exato de operações, faça uma estimativa por ordem de grandeza: eventos/dia vs checagens/dia.
5) Projete confiabilidade: retry, backoff, DLQ e idempotência
Webhook falha por timeout, instabilidade ou pico. Polling falha por rate limit e janelas de tempo. Em ambos, você precisa: (a) retry com backoff para 429/5xx, (b) registro de último cursor (timestamp/ID), (c) idempotência para não duplicar, e (d) “caixa de quarentena” (DLQ) para reprocessar depois.
6) Decida um padrão (e documente o porquê)
Se o evento for crítico: use webhook + reconciliação. Se o evento for útil mas não crítico: webhook apenas ou polling leve. Se o sistema não tem webhook ou é ruim: polling com cursor e tolerância a rate limit. Escreva a decisão em uma linha: “Escolhemos X porque Y, e mitigamos Z com W”.
Webhook vs polling: diferenças que importam na vida real
No discurso, webhook é “moderno” e polling é “antigo”. Na operação, os dois são só estratégias de entrega de eventos — e ambas quebram se você não desenhar o fluxo para falhar com dignidade.
Webhook é o sistema te avisando. Polling é você perguntando periodicamente. O que muda é latência, volume de chamadas e o tipo de erro que aparece (timeout vs rate limit, por exemplo).
| Critério | Webhook | Polling |
|---|---|---|
| Latência | Baixa (quase em tempo real, depende da fila do provedor) | Depende do intervalo (segundos a horas) |
| Custo por execução | Geralmente menor (executa quando tem evento) | Pode ser alto (executa mesmo sem evento) |
| Confiabilidade | Boa se houver reentrega + idempotência; ruim se o provedor “manda uma vez e pronto” | Boa para reconciliação, mas pode perder mudanças entre janelas se não usar cursor correto |
| Complexidade de infraestrutura | Precisa endpoint público, TLS e observabilidade | Pode rodar só “saindo” para a API (mais fácil em redes restritas) |
| Erros típicos | Timeout no endpoint, eventos duplicados, payload incompleto | Rate limit (429), paginação/cursor mal feito, atrasos e custo |
| Melhor uso | Disparar automações e ações imediatas | Conferir consistência e buscar alterações quando não há webhook |
O padrão que mais funciona: webhook para disparar, polling para reconciliar
Em operações brasileiras (principalmente quando tem WhatsApp, e-commerce e ERPs), o “mundo perfeito” raramente acontece: webhooks podem atrasar, duplicar ou simplesmente não chegar quando há instabilidade.
O arranjo mais resiliente costuma ser: (1) webhook cria um registro do evento e coloca em fila; (2) um job periódico faz polling para garantir que nada ficou para trás; (3) ambos escrevem no mesmo armazenamento com idempotência (chave única) para evitar duplicidade.
- Webhook recebe o evento e salva: event_id + tipo + timestamp + payload bruto
- Workflow valida assinatura/origem e normaliza dados
- Processamento principal roda com retry/backoff
- Polling roda a cada X minutos buscando “desde o último cursor”
- Tudo passa por idempotência (ex.: event_id, order_id, payment_id) antes de acionar ações externas
Checklist rápido de decisão (sem romantizar tecnologia)
Use este checklist como regra de bolso. Se você marcar muitos itens do lado do polling, não é “fracasso”: é só adequação ao contexto.
- Precisa responder em segundos/minutos? → webhook
- A fonte não tem webhook ou é inconsistente? → polling (com cursor) ou híbrido
- Você não consegue manter endpoint público estável (TLS/DNS/VPS)? → polling ou híbrido com fila
- Você tem limite agressivo de API e pouco orçamento de execuções? → webhook primeiro, polling só para reconciliação
- Você já sofreu com eventos duplicados? → idempotência obrigatória (independe da escolha)
- O provedor reentrega webhook em falha? Se não souber → trate como “não” e planeje reconciliação
Armadilhas comuns (e como evitar sem reinventar a roda)
1) Polling sem cursor: buscar “últimos 50” e torcer para não perder. Isso falha quando o volume cresce. Use timestamp + paginação, ou um ID incremental, e armazene o último processado.
2) Webhook sem validação: aceitar qualquer POST é pedir para ter incidente. Mesmo sem dados sensíveis, valide assinatura quando existir e restrinja origem (quando possível).
3) Falta de idempotência: o webhook duplicou? o polling pegou de novo? Sem idempotência, você manda duas cobranças, cria dois tickets, dispara duas mensagens.
4) Retry sem backoff: insistir rápido em 429/5xx só piora. Use backoff exponencial e um limite de tentativas, com DLQ para o que estourar.
Perguntas frequentes
Webhook sempre é melhor que polling?
Como evitar eventos duplicados em webhook e polling?
Qual intervalo de polling devo usar?
Dá para combinar webhook e polling sem aumentar muito o custo?
Leia também
Webhook
Entenda o que é webhook, como funciona na prática e como usar no n8n e Make para criar automações em tempo real sem precisar saber programar.
Ler →
Como fazer idempotência em automações com webhook (e parar de duplicar pedidos, notas e leads)
Guia direto para aplicar idempotência em automações com webhook: chaves idempotentes, deduplicação, banco/planilha, retries e boas práticas para n8n/Make/Zapier.
Ler →
Rate limit, retry e backoff: como parar de quebrar automação em API (n8n, Make, Zapier)
Guia direto para lidar com rate limit (429), retries e backoff em automações com APIs. Aprenda padrões práticos para n8n, Make e Zapier e evite falhas intermitentes, duplicidades e banimentos.
Ler →
Como usar Dead Letter Queue (DLQ) em automações: trate falhas sem perder eventos
Guia prático de Dead Letter Queue (DLQ) para automações: quando usar, como modelar eventos, reprocessar com segurança e evitar duplicidade em n8n/Make/Zapier.
Ler →