Integrações e Webhooks

Nenhuma empresa opera com um único sistema. O CRM registra clientes. O ERP gerencia pedidos e financeiro. A plataforma de e-commerce processa vendas. O sistema de suporte rastreia atendimentos. O sistema de marketing automatiza comunicações. Cada um desses sistemas existe para resolver um problema específico — e nenhum deles foi construído para conversar com os outros por padrão.

O resultado sem integração é trabalho manual de ponte: alguém exporta dados de um sistema, importa em outro, ou simplesmente redigita a informação. É lento, caro e propenso a erro. Integração é o trabalho de fazer sistemas diferentes trocarem dados automaticamente, em tempo real ou em batch, sem intervenção humana.

Webhooks são um dos mecanismos mais práticos para integração em tempo real: em vez de um sistema perguntar periodicamente "tem novidade?", ele registra um endereço onde quer ser notificado, e o outro sistema avisa quando algo acontece.

A distinção mais importante em integração em tempo real é entre dois padrões opostos.

Polling é a abordagem ativa: o sistema A pergunta ao sistema B a cada intervalo de tempo se há novidade. "Tem novo pedido? Não. Tem novo pedido? Não. Tem novo pedido? Sim!" Polling é simples de implementar mas ineficiente — a maioria das perguntas não tem novidade, e ainda assim consomem banda e processamento. Para detectar eventos em tempo real, o intervalo precisa ser curto; intervalos curtos multiplicam o overhead.

Webhook é a abordagem reativa: o sistema A registra no sistema B um URL onde quer ser notificado. Quando algo acontece no sistema B, ele faz uma requisição HTTP para esse URL com os dados do evento. O sistema A recebe a notificação apenas quando há algo para receber — sem overhead de polling, com latência próxima a zero.

A analogia: polling é ligar para a pizzaria a cada 5 minutos para saber se sua pizza ficou pronta. Webhook é deixar seu número com a pizzaria e receber uma ligação quando a pizza sair do forno.

Registro: o sistema que quer ser notificado registra um endpoint (URL) no sistema que vai notificar. Normalmente feito via painel de configuração ou via API. "Quando um pagamento for confirmado, faça um POST para https://minha-empresa.com/webhooks/pagamento."

Disparo: quando o evento ocorre no sistema fonte, ele faz uma requisição HTTP POST para o endpoint registrado, com payload JSON descrevendo o evento.

Processamento: o sistema receptor processa o evento — atualiza banco de dados, envia e-mail, aciona outro sistema. A resposta deve ser rápida (idealmente abaixo de 5 segundos) — processamento lento deve ser delegado a fila de background.

Confirmação: o receptor responde com HTTP 200 para confirmar que recebeu o webhook. Se o receptor não responde 200, o sistema fonte normalmente tenta reenviar — com backoff exponencial. Isso exige que o processamento do webhook seja idempotente — receber o mesmo evento duas vezes não deve causar duplicação.

Segurança: webhooks chegam via HTTP — qualquer um que conheça o URL pode enviar requisição falsa. A proteção padrão é assinatura HMAC: o sistema fonte inclui um header com a assinatura criptográfica do payload usando um segredo compartilhado. O receptor verifica a assinatura antes de processar.

Webhooks resolvem notificações em tempo real, mas integração completa entre sistemas usa múltiplos mecanismos dependendo do caso.

APIs REST síncronas: quando o sistema A precisa de uma resposta imediata do sistema B para continuar. Consultar dados de um cliente no CRM antes de exibir a tela. Verificar disponibilidade de estoque antes de confirmar pedido. A chamada é síncrona — espera a resposta.

Batch / ETL: transferência de grandes volumes de dados em lote, normalmente agendada. Sincronização diária de dados entre sistemas, geração de relatórios, carregamento de data warehouse. Não é tempo real, mas é eficiente para grandes volumes.

Filas de mensagem: para integração assíncrona com garantia de entrega e processamento em volume. O sistema A publica uma mensagem na fila; o sistema B consome quando pode. Mais robusto que webhook direto para cenários de alto volume ou consumidor lento.

iPaaS (Integration Platform as a Service): plataformas como Zapier, Make (ex-Integromat), n8n e MuleSoft que fornecem conectores pré-construídos para centenas de sistemas e interface visual para construir fluxos de integração sem código. Para integrações entre sistemas SaaS comuns, iPaaS reduz o tempo de implementação de semanas para horas.

Versioning e breaking changes: o sistema B atualiza sua API e muda o formato do payload. Todas as integrações que dependem desse formato quebram simultaneamente. APIs bem projetadas versionam explicitamente (v1, v2); integrações bem construídas tratam campos ausentes com tolerância.

Falhas silenciosas: webhook que não chega, fila que para de consumir, polling que retorna dado desatualizado. Sem monitoramento ativo das integrações, problemas ficam invisíveis até que alguém percebe que os dados estão errados ou atrasados.

Reprocessamento: quando um webhook falha ou é perdido, como garantir que o evento seja reprocessado sem duplicar dados? Idempotência no processamento (baseada em ID único do evento) é o padrão.

Gestão de segredos: chaves de API e segredos de webhook precisam ser armazenados de forma segura, rotacionados periodicamente e revogados quando um sistema é comprometido. Segredos em código-fonte ou planilha são vulnerabilidade real.

Integração de sistemas é onde PMEs têm o maior gap entre o que é possível e o que está sendo feito. A maioria das PMEs opera com três a cinco sistemas que não conversam entre si — resultando em trabalho manual de re-digitação, dados inconsistentes e visibilidade limitada da operação.

O ponto de partida mais acessível hoje são plataformas de iPaaS como Zapier e Make, que oferecem centenas de integrações pré-construídas para os sistemas mais comuns (Salesforce, HubSpot, Shopify, Google Sheets, Slack, WhatsApp Business) sem código. Uma integração que levaria semanas de desenvolvimento pode ser construída em horas por alguém sem background técnico.

Para integrações mais complexas ou de maior volume, a decisão entre iPaaS, desenvolvimento custom via API e message queue depende do volume de dados, da latência aceitável e da equipe disponível. O critério não é tecnológico — é identificar qual trabalho manual de sincronização de dados custa mais tempo e cria mais erro, e atacar esses pontos primeiro.