Webhooks em ERPs brasileiros: guia técnico Bling, Omie, TOTVS

Por Alexandre Pereira · 15 de julho de 2026 · 5 min de leitura

Integrar sistemas em tempo real sem polling constante é o que separa processos ágeis de filas que engasgam. Webhooks em ERPs brasileiros prometem isso, mas a realidade varia: Bling entrega eventos nativos robustos, Omie cobre alguns fluxos, ContaAzul pede polling e TOTVS depende de trigger SQL ou middleware. Saber o que cada plataforma oferece — e onde você precisa construir — economiza semanas de retrabalho.

Este guia mapeia suporte real de webhooks em Bling, Omie, ContaAzul e TOTVS, detalha assinatura HMAC para segurança, idempotência e mostra um caso onde pedido aprovado dispara emissão de NF e notificação WhatsApp em 8 segundos.

Qual ERP brasileiro tem webhooks nativos e quais eventos cobrem?

Bling oferece webhooks nativos para pedido criado, pedido aprovado, produto alterado, estoque modificado e nota fiscal emitida. A documentação publica URL de callback, header de autenticação e payload JSON completo. Assinatura HMAC-SHA256 no header X-Bling-Signature valida origem — você reconstrói o hash com chave secreta e compara. Uma distribuidora capixaba com 120 SKUs usa webhook de pedido aprovado para acionar n8n: emite NF no Bling, registra no Supabase e envia comprovante por WhatsApp Business API em 8 segundos — antes levava 40 minutos com checagem manual a cada 15 min.

Omie entrega webhooks para alguns eventos: pedido de venda incluído, cliente alterado, projeto finalizado. Cobertura é menor que Bling e documentação menos detalhada — eventos de estoque e NF pedem polling via GET a cada 2-5 minutos. Assinatura usa token fixo no header Authorization, sem HMAC; valide IP de origem (lista publicada na doc) para evitar spoofing. Idempotência é crítica: armazene event_id recebido e ignore duplicatas — Omie pode reenviar o mesmo evento em failover.

ContaAzul não oferece webhooks nativos até julho de 2026. Integração pede polling: GET /vendas?data_inicio=2026-07-15T00:00:00 a cada 3-10 minutos, salva último timestamp processado e filtra delta. Para emitir NF automaticamente, agende job que consulta vendas aprovadas, chama POST /nfe e notifica. Latência fica entre 3-10 minutos conforme intervalo de polling — aceitável para fluxos não críticos, mas pesado se volume de transações passar de 500/dia.

TOTV depende do módulo. Protheus e Datasul não expõem webhooks HTTP nativos; solução comum é trigger SQL na tabela SC5 (pedidos) que insere em fila intermediária, consumida por serviço Node.js ou Python que chama API externa. RM e Fluig possuem eventos internos (Workflow ou API REST), mas configuração exige licença de middleware — muitas PMEs partem de exportação batch CSV a cada hora, processada via n8n Schedule Trigger. Latência varia de 5 minutos (trigger SQL + serviço) até 60 minutos (batch).

Como garantir segurança e idempotência em webhooks de ERP?

Assinatura HMAC valida que payload veio do ERP, não de atacante. Bling envia X-Bling-Signature: sha256=abc123; você reconstrói hash SHA256 do body com chave secreta (painel API > Webhooks) e compara string. Se diferir, rejeita com HTTP 401. Omie usa token fixo no header; valide também IP de origem (189.x.x.x ranges publicados). Grave log de tentativa com timestamp, IP e hash para auditoria — detecta replay attack se mesmo payload chegar 2x em 10s.

Idempotência evita processar evento duplicado. Webhook pode reenviar em timeout de rede ou failover: salve event_id ou pedido_id + timestamp em tabela processed_events (unique constraint) antes de executar ação. Se insert falhar por duplicate key, retorne HTTP 200 sem reprocessar — ERP interpreta como sucesso. Uma rede varejista em Vitória registrou 11% de eventos duplicados em pico de Black Friday; idempotência impediu emissão de NF em duplicidade, economizando R$ 18 mil em multas fiscais.

Retry logic do ERP espera HTTP 2xx em até 5s; se demorar, reenvia até 5 vezes com backoff exponencial. Responda rápido: webhook recebe evento, valida assinatura, insere em fila Supabase ou Redis e retorna 200 — processamento assíncrono consome fila depois. Se lógica demorar (chamar TOTVS, gerar PDF), timeout estoura e ERP desiste, perdendo evento. Use n8n Webhook node com Respond immediately ativado.

Caso real: pedido aprovado dispara NF e WhatsApp em 8 segundos

Distribuidora de material elétrico em Serra, ES, com 180 funcionários e 400 pedidos/dia no Bling enfrentava 40 minutos entre aprovação comercial e envio de NF ao cliente — analista checava painel a cada 15 min, baixava XML, enviava email. Implementamos webhook de pedido aprovado apontando para n8n na nuvem: valida assinatura HMAC, extrai pedido_id, chama POST /nfe no Bling (emissão automática), salva XML no Supabase Storage, envia mensagem WhatsApp Business API com link de download. Latência end-to-end: 8 segundos. Analista virou exceção: só age se webhook falhar (alerta Slack).

Volume processado subiu de 400 para 680 pedidos/dia sem contratar — automação absorveu pico de junho. Taxa de erro caiu de 7% (esquecimento, envio para cliente errado) para 0,4% (falha de API). Custo: R$ 320/mês (n8n Pro + Supabase + WhatsApp Business), contra R$ 9 mil/mês de um analista dedicado. ROI em 18 dias.

Quem quer começar pode partir de um piloto de 30 dias: escolha 1 evento crítico (pedido aprovado, estoque zerado), configure webhook no ERP, aponte para n8n gratuito (self-hosted) e valide com 20-50 eventos reais antes de escalar.