Webhook vs Polling na integração com CRM: quando usar (e como evitar falhas silenciosas)
- Webhook entrega evento; polling busca estado. Isso muda custo, latência e chance de perder mudanças.
- Webhook exige endpoint público, segurança (assinatura) e idempotência para evitar duplicidade.
- Polling exige estratégia de janela (desde-quando) e controle de rate limit para não derrubar APIs.
- O melhor desenho costuma ser híbrido: webhook para o quente + polling para reconciliar e corrigir gaps.
O que muda, na prática: evento vs estado
A diferença que decide quase tudo é conceitual: webhook costuma ser orientado a evento (um “lead criado”, “negócio mudou de etapa”), enquanto polling é orientado a estado ("me dê tudo que mudou desde X").
Integração orientada a evento é rápida e econômica quando bem implementada. Mas é frágil se você não tratar perda de entrega, duplicidade e ordem dos eventos. Já o polling é mais previsível para auditoria e reconciliação, porém mais caro em chamadas e sujeito a dados “atrasados” por definição.
Comparativo direto: webhook vs polling
Não existe “o melhor”. Existe o que encaixa no seu risco operacional, volume, limites de API e exigência de tempo de resposta.
| Critério | Webhook | Polling |
|---|---|---|
| Latência | Baixa (quase imediata, dependendo de filas/retries) | Média/alta (depende do intervalo de consulta) |
| Carga em API | Tende a ser menor (chama só quando há evento) | Tende a ser maior (consultas mesmo sem mudança) |
| Risco de duplicidade | Alto se não houver idempotência e dedupe | Médio (pode repetir itens em janelas sobrepostas) |
| Risco de perder mudanças | Existe (falhas de entrega, timeouts, indisponibilidade do receiver) | Existe (janelas mal definidas, “buracos” em timestamps, paginação) |
| Observabilidade | Precisa de logs de entrega, status codes e DLQ/filas | Precisa de logs de execuções, checkpoints e contadores por página |
| Reprocessamento | Mais chato: você reenvia eventos ou reconcilia via busca | Mais natural: basta voltar o checkpoint (com cuidado) |
| Complexidade de segurança | Maior (assinatura, validação, replay protection) | Menor (API client + credenciais, ainda com boas práticas) |
| Quando brilha | Roteamento de leads, alertas, automações sensíveis a tempo | Sincronização de base, auditoria, integrações com histórico grande |
Quando escolher webhook (cenários típicos de CRM)
Webhook costuma ser a escolha certa quando a operação “sente” atraso: SDR precisa ligar enquanto o lead está quente; atendimento precisa ver o contexto logo após uma interação; uma mudança de etapa aciona aprovação, tarefa ou handoff.
Mesmo assim, webhook bom não é só “receber e gravar”. É receber, validar, enfileirar, processar com idempotência e registrar rastreabilidade.
- Distribuição de leads em tempo quase real (roteamento e SLA de primeira resposta).
- Atualização imediata de status (ex.: pagamento aprovado → liberar onboarding).
- Alertas operacionais (ex.: negócio voltou etapa, risco, cobrança, disputa).
- Integrações em que o volume é imprevisível (você não quer “consultar à toa”).
Quando escolher polling (sem romantizar)
Polling é subestimado porque parece “antigo”, mas resolve problemas reais: ausência de webhook, webhooks incompletos (não cobrem todos os objetos), ambientes com restrição de inbound, ou necessidade forte de reconciliação.
Também é o caminho quando você precisa tratar consistência: comparar o que está no CRM com o que está no ERP, no gateway de pagamento ou no data warehouse e corrigir diferenças.
- Sistemas que não oferecem webhook ou oferecem de forma limitada/instável.
- Backfill (importação histórica) e sincronização inicial com grande volume.
- Rotinas de reconciliação: garantir que nada ficou para trás (anti “falha silenciosa”).
- Cenários com fortes limites de infraestrutura para expor endpoints públicos.
O desenho que dá menos dor: webhook + polling de reconciliação
Na prática editorial do setor, o padrão mais resiliente é híbrido: webhook para agilidade e polling periódico para conferir se o mundo está consistente. Isso reduz a dependência cega de um único mecanismo.
O polling aqui não precisa ser frequente; ele existe para detectar buracos, corrigir atrasos e reprocessar com critério.
- Webhook processa eventos e grava um “event_id” (ou hash) para deduplicar.
- Fila/DLQ guarda falhas para reprocessamento (sem perder evento no 500/timeout).
- Polling diário (ou por janela) reconcilia registros alterados e compara contagens.
- Relatórios de divergência viram trabalho de correção, não caça ao fantasma.
Checklist anti-falha silenciosa (vale para os dois)
Falha silenciosa é quando “parece que está tudo ok” porque ninguém está olhando — até o time notar lead sumindo, etapa errada, ou duplicidade em massa. Dá para prevenir com disciplina técnica e governança.
- Idempotência: o mesmo evento/processamento repetido não pode gerar duplicidade.
- Checkpoint explícito (polling): guardar o último cursor/timestamp processado com margem e dedupe.
- Monitoramento: taxa de sucesso, latência, backlog de fila, erros por endpoint, e alarmes por anomalia.
- Auditoria: logs com correlação (ID do objeto no CRM + origem + horário + payload resumido).
- Contratos de dados: definir quais campos são “fonte de verdade” e quem pode sobrescrever quem.
- Testes de caos controlados: simular atraso, repetição e indisponibilidade para ver se o sistema se recupera.
Perguntas frequentes
Webhook é sempre em tempo real?
Polling vai estourar o limite de API do CRM?
Como evitar duplicidade quando o webhook reenvia o mesmo evento?
Quando faz sentido abandonar webhook e ficar só no polling?
Leia também
Integração do CRM em tempo real vs. em lote (batch): quando escolher e como evitar caos de dados
Comparativo prático entre integrar o CRM em tempo real (eventos/webhooks) ou em lote (batch): latência, custo, confiabilidade, governança e como decidir sem criar duplicidade e conflitos.
Ler →
Automação nativa do CRM vs iPaaS: quando usar (e como evitar integração frágil)
Entenda quando vale ficar na automação nativa do CRM e quando um iPaaS faz sentido. Veja impactos em dados, governança, custos ocultos, manutenção e um checklist prático para decidir sem criar um emaranhado de integrações.
Ler →
Governança de integrações no CRM: como evitar dados duplicados e automações conflitantes
Guia prático para organizar integrações do CRM (WhatsApp, e-mail, ERP, formulários e automação), definir dono, versionar mudanças e impedir contatos duplicados e fluxos que brigam entre si.
Ler →
ETL vs Reverse ETL no CRM: quando usar (e como evitar dados duplicados)
Entenda a diferença entre ETL e Reverse ETL no contexto de CRM, quando cada abordagem faz sentido e quais controles evitam duplicidade, conflito de campos e automações quebradas.
Ler →