Como integrar WhatsApp com CRM via webhook: o fluxo pronto da Flly com n8n

Integrar WhatsApp com CRM (sistema de gestão de relacionamento de clientes) via webhook segue um caminho técnico bem definido, sem conector mágico de um clique: a Flly dispara um webhook (aviso automático que um sistema envia a outro quando algo acontece) a cada evento da conversa, o n8n (automação visual que liga sistemas sem programar do zero) ou o Make recebe esse aviso, normaliza o telefone e atualiza o contato no CRM, criando um card ou movendo a etapa quando a inteligência artificial (IA) qualifica o lead (cliente potencial). Numa operação que já gera muitos leads (clientes potenciais) por semana, esse fluxo tem custo e pontos de falha que dá pra orçar antes de contratar qualquer freelancer. Este texto mostra os eventos exatos, um fluxo pronto pro n8n, o mapeamento de campos nos principais CRMs e quando vale pedir a implantação da Flly em vez de montar sozinho.

Quem ainda não decidiu entre as três arquiteturas de integração, CRM com WhatsApp embutido, atendimento com CRM nativo ou integração por automação, encontra a visão de conjunto no texto sobre como funciona a integração entre CRM e WhatsApp. Aqui o foco é mais estreito: o passo a passo de quem já escolheu o caminho do webhook.

Segundo pesquisa da ActiveCampaign em parceria com a AnaMid, de setembro de 2025, 79,3% das empresas brasileiras já usam o WhatsApp no negócio, mas só 41,2% fazem isso de forma automatizada, e 13,9% nem sabem diferenciar a API (interface que deixa dois sistemas conversarem) oficial da não oficial.

Fonte: ChatSAC, com dados de ActiveCampaign e AnaMid. Quase oito em cada dez empresas já usam o WhatsApp, e a maioria ainda copia dado na mão entre sistemas por nunca ter montado esse webhook.

A Flly emite dezenove eventos de webhook cobrindo a jornada inteira do lead

Webhook de saída é o aviso que ela manda pra fora toda vez que algo muda numa conversa. São dezenove eventos ao todo, em oito famílias: conversa (criada, atualizada, fechada, mudança de modo entre IA e humano, mudança de status do lead, mudança de tags, roteada), mensagem (recebida, enviada), contato criado, tag (criada, atualizada, removida), agente (criado, atualizado, removido), reunião agendada, campanha concluída e follow-up (voltar no cliente em potencial para lembrá-lo) enviado. Quem integra com CRM externo usa só uma fração desse total: contact.created abre o card, conversation.lead_status_changed com valor QUALIFIED move a etapa, e meeting.scheduled cria a atividade do vendedor.

Cada entrega fica registrada num log com sucesso ou falha, o payload enviado e a resposta que o outro lado devolveu, o que ajuda a debugar sem abrir chamado de suporte. Vem junto um teste de ping manual pra validar a URL antes de ligar o fluxo de verdade, retry automático quando a entrega falha, e uma assinatura HMAC (assinatura criptográfica que prova que o aviso veio de quem diz ter enviado, e não foi alterado no caminho) opcional. É o mesmo princípio do cabeçalho X-Hub-Signature-256 que a Meta usa nos webhooks do WhatsApp: sem essa validação, qualquer um com a URL do fluxo manda evento falso.

Webhooks de entrada abrem uma porta única pra leads que nascem fora da Flly

A via contrária também existe. Um webhook de entrada é um endereço único, protegido por token, que a Flly disponibiliza pra outros sistemas mandarem lead pra dentro da plataforma e disparar uma ação, quase sempre abrir uma conversa nova e colocar a inteligência artificial pra qualificar. É o caminho mais comum pra trazer lead de anúncio da Meta, de formulário do site ou de um CRM que só precisa que o WhatsApp responda rápido.

Quem já roda lead de anúncio encontra o passo a passo completo no texto sobre integração entre Meta Ads e WhatsApp com IA. O importante aqui é que as duas pontas trabalham juntas: o lead entra pelo webhook de entrada, a IA qualifica, e o webhook de saída avisa o CRM de gestão, fechando o ciclo sem digitação manual.

O fluxo de referência em n8n tem sete passos, do gatilho ao card atualizado no CRM

Esse é o fluxo que a gente monta com clientes que já têm um CRM de gestão e querem receber lá o que a Flly qualifica no WhatsApp. Funciona quase igual em n8n ou em Make, e cobre os pontos onde a maioria das integrações caseiras quebra.

1. Gatilho: um nó de webhook no n8n recebe o POST que ela envia assim que o evento acontece, com o payload completo da conversa e do lead.
2. Validação: confere a assinatura HMAC e o timestamp do aviso, e descarta qualquer requisição fora do padrão antes de tocar no CRM.
3. Resposta rápida: devolve um código de sucesso (2xx) em até 2 segundos e joga o processamento pesado pra uma fila, porque emissor sério de webhook trata demora como falha e tenta de novo.
4. Normalização do telefone: converte o número pro formato E.164 (padrão internacional de telefone, sempre com o sinal de mais, o código do país e até 15 dígitos, por exemplo mais 55 11 99999 9999), porque é assim que a maioria dos CRMs busca contato duplicado.
5. Busca do contato: procura no CRM pelo telefone normalizado e, quando existe, pelo e-mail também, pra decidir entre criar registro novo ou atualizar o que já existe.
6. Atualização do card: cria o contato se ele não existir, move a etapa do funil quando o evento é conversation.lead_status_changed com valor QUALIFIED, e anexa o resumo que a inteligência artificial escreveu como nota na timeline do lead.
7. Ação final: quando chega meeting.scheduled, cria uma atividade ou tarefa pro vendedor responsável, com data, horário e link da reunião.

Nenhum desses passos exige mais que uns nós de HTTP Request, IF e Set dentro do n8n. A diferença entre uma integração que funciona e uma que gera card duplicado toda semana mora nos passos 2, 3 e 5, exatamente os que tutorial genérico costuma pular.

O mapeamento de campos muda de CRM pra CRM, e ignorar isso duplica contato

Cada CRM identifica contato repetido, aceita webhook e cobra tempo de resposta de um jeito diferente, e o mesmo fluxo de sete passos precisa de ajuste fino dependendo de qual sistema recebe o lead no fim da linha.

| CRM | Como identifica contato duplicado | Timeout de resposta do webhook | Retentativas em falha | Assinatura do webhook | | --- | --- | --- | --- | --- | | RD Station CRM | Sem busca nativa por telefone documentada; eventos trazem um transaction_uuid reaproveitável como chave | 5 segundos | 5 tentativas | Token na requisição, sem HMAC documentado | | Pipedrive | Endpoint de busca de pessoas aceita fields=phone e exact_match=true | 10 segundos | 3 tentativas, em 3, 30 e 150 segundos | HTTP Basic Auth | | HubSpot | Deduplica automático só por e-mail; telefone exige campo customizado único ou busca prévia | 5 segundos | 10 tentativas em 24 horas | HMAC SHA-256 v3, com tolerância de 5 minutos no timestamp | | Kommo | Sem busca nativa por telefone documentada; limite de 7 requisições por segundo | 2 segundos | 5 min, 15 min, 15 min, 1 hora | Sem HMAC documentado |

O detalhe que mais gera card duplicado é a deduplicação por telefone: HubSpot não faz isso sozinho, então o passo 5 vira obrigatório. No Pipedrive é nativo, e no Kommo o limite de 7 requisições por segundo pesa mais, porque um disparo em lote esbarra nesse teto antes de atualizar todo mundo.

Idempotência e retries decidem se a integração aguenta um pico de leads

Idempotência é a garantia de que processar o mesmo evento duas vezes dá o mesmo resultado de processar uma vez só, o que falta na maioria dos fluxos montados às pressas. A documentação de webhooks do Stripe, referência de mercado, recomenda guardar o identificador de cada evento processado e ignorar repetição com o mesmo identificador, porque reenvio por timeout ou erro momentâneo do CRM é esperado, não exceção.

Esse cuidado cresce com o volume. A Terramundi, boutique de viagens que qualificou 1.037 leads pela inteligência artificial num único mês, segundo o case público da Flly, opera numa escala em que webhook duplicado sem controle de identificador vira problema rápido: dezenas de eventos por dia, às vezes concentrados em horas de campanha, e cada reenvio sem checagem de idempotência gera um card a mais pro time comercial disputar.

Do lado de quem chama a API do CRM, o erro muda por sistema: Bitrix24 devolve 503 (QUERY_LIMIT_EXCEEDED) ao estourar 2 requisições por segundo no plano comum, Kommo devolve 429 acima de 7 por segundo, e Pipedrive usa orçamento diário de tokens por usuário. Em todos, a resposta certa é recuar com backoff exponencial, porque insistir na hora só prolonga o bloqueio.

HMAC e o mínimo necessário de dado trafegado protegem a integração e a LGPD

A LGPD (Lei Geral de Proteção de Dados) entra na conversa no momento de decidir o que trafega nesse fluxo. A prática que funciona é mandar pro CRM só o que o vendedor precisa pra agir: nome, telefone, etapa, origem da campanha e o resumo que a IA já escreveu, evitando o histórico inteiro da conversa. Guardar a conversa completa em dois sistemas dobra a exposição de dado pessoal sem dobrar resultado comercial, já que o vendedor decide a próxima ligação lendo o resumo, não o histórico linha por linha.

Ativar a assinatura HMAC na Flly custa uma linha de configuração e evita que qualquer pessoa que descubra a URL do fluxo injete evento falso. O padrão é o mesmo que a HubSpot documenta pra validar seus webhooks: HMAC SHA-256 sobre o método, a URL e o corpo da requisição, mais um timestamp, com tolerância de 5 minutos.

Montar sozinho custa entre R$ 400 e R$ 10.000, e às vezes compensa mais pedir a implantação da Flly

| Caminho | Custo típico no Brasil | Quando faz sentido | | --- | --- | --- | | Automação simples em n8n (1 evento, 1 CRM) | R$ 400 a R$ 900 por projeto | Só criar o card quando contact.created dispara | | Fluxo intermediário (o de sete passos deste texto) | R$ 900 a R$ 2.500 | Idempotência, busca por telefone e mudança de etapa | | Projeto avançado (vários CRMs ou sistemas juntos) | R$ 2.500 a R$ 10.000 ou mais | CRM, ERP (sistema de gestão financeira e operacional) e financeiro na mesma automação | | Manutenção mensal do fluxo | R$ 500 a R$ 3.000 por mês | Ajustar quando o CRM muda campo ou surge evento novo | | Servidor pra n8n auto-hospedado | R$ 25 a R$ 100 por mês | Time técnico próprio disposto a manter infraestrutura |

Esses números vêm de projetos reais de automação no Brasil. Vale de referência: até a RD Station, que já vende o próprio CRM, cobra à parte pra ativar o número oficial de WhatsApp (R$ 1.999, pagamento único) e pra integrar o chatbot da própria RD ao próprio CRM (R$ 3.799), prova de que o custo de implantação é o preço normal de qualquer integração feita direito, mesmo dentro do mesmo fornecedor.

Quando o cliente não tem time técnico disponível, ou não quer gastar semanas testando fluxo, a Flly assume como projeto de implantação: alinha o escopo, cobra o valor de implementação de forma transparente e entrega funcionando, sem o cliente mexer em nada. Foi assim em projetos de consultoria que já integraram a Flly a PipeRun e a Bitrix24, dois CRMs com API documentada e webhook de saída, exatamente o que esse tipo de projeto precisa.

Esse fluxo é uma peça dentro de uma arquitetura maior: o mapa completo, do primeiro contato até o relatório mensal, está no guia de automação comercial com IA e WhatsApp, e o comparativo de custo cenário a cenário está no texto sobre quanto custa automatizar o comercial e o administrativo com IA.

Perguntas frequentes

A Flly tem conector nativo com HubSpot, RD Station ou Pipedrive?

Não. O caminho é webhook de saída mais automação (n8n, Make ou Zapier), ou um projeto de implantação feito pelo time da Flly. Boa parte dos clientes acaba usando só o CRM Kanban nativo da própria plataforma e nunca chega a precisar dessa integração.

Preciso saber programar pra montar esse fluxo no n8n?

Não no sentido de escrever código, mas ajuda entender IF, HTTP Request e um pouco de JSON. Quem não tem essa familiaridade contrata um freelancer, dentro da faixa de R$ 900 a R$ 2.500 da tabela, ou pede a implantação completa.

O que acontece se o CRM demorar mais que o timeout, como os 2 segundos do Kommo?

A entrega conta como falha e a Flly tenta de novo, pela política de retry automático. Por isso o passo 3, responder rápido e processar depois numa fila, importa tanto: quem atualiza o CRM antes de devolver a resposta corre o risco de estourar o timeout e gerar reenvio duplicado.

Dá pra usar Zapier em vez do n8n?

Dá, mas dois detalhes mudam o cálculo. O Zapier só libera gatilho por webhook a partir do plano Professional (750 tasks por mês), porque o plano gratuito busca atualização a cada 15 minutos, sem tempo real. Isso atende bem a qualificação de lead, mas o custo por operação sobe mais rápido que no n8n auto-hospedado conforme o volume cresce.

Qual evento eu uso pra criar o card e qual pra mover de etapa no CRM?

contact.created cria o card assim que a conversa começa, e conversation.lead_status_changed com valor QUALIFIED move pra etapa de qualificados. meeting.scheduled fica reservado pra criar a atividade do vendedor, e message.received ou message.sent costumam ficar de fora, porque sincronizar o histórico inteiro de mensagem raramente vale o dado pessoal extra trafegado.

O card que atualiza sozinho no CRM paga essa integração já no primeiro mês

Um vendedor que abre o CRM de manhã e encontra os leads do dia anterior já qualificados, já na etapa certa, com o resumo da conversa colado na timeline, economiza um tempo que normalmente vai pra digitação. Multiplicado por um time inteiro, esse tempo é o retorno mais fácil de defender numa reunião de orçamento, mesmo antes de olhar pra taxa de conversão.

Se preferir ver os eventos, o log de entregas e o teste de ping funcionando antes de escrever qualquer fluxo, entre no teste grátis da Flly e converse com o Miguel, SDR (pré-vendedor ou atendente inicial) de inteligência artificial, pelo WhatsApp: ele mostra o card andando sozinho quando o webhook está de fato configurado.