Trazer leads e etapas do seu CRM para o centro pelo webhook genérico

Nem todo sistema tem conector pronto — o CRM próprio, a planilha automatizada, o sistema da agência. O webhook genérico é a porta para eles: um contrato pequeno (evento, e-mail, telefone, quando, dados livres), e o lead entra na mesma linha do tempo que o pixel e a Hotmart. Este é o contrato e os erros que ele evita.

Hotmart, Meta Ads, Google Ads, formulários: têm conector. O sistema onde o seu time comercial trabalha muitas vezes não tem — é um CRM menor, uma automação de WhatsApp, um sistema feito em casa. E é exatamente nele que acontece a parte da história que falta na base: quem respondeu, quem conversou, quem comprou por fora.

O webhook genérico é a porta para isso. Ele não sabe nada sobre o seu sistema; sabe receber um acontecimento com identidade e colocá-lo na pessoa certa — que é o trabalho de leads centralizados. Numa conta que acompanhamos, o CRM manda 56 mil eventos por mês por esse caminho — mais do que qualquer fonte fora do pixel — e cada um deles casa com o lead que o anúncio trouxe.

O contrato

{
  "event": "crm.opportunity.client_replied",
  "email": "pessoa@exemplo.com",
  "phone": "+5511999990000",
  "occurred_at": "2026-09-11T14:32:10-03:00",
  "data": {
    "produto": "Mentoria Fluxo",
    "pipeline": "Perpétuo",
    "etapa_de": "Base",
    "etapa_para": "Respondeu",
    "vendedor": "ana-paula",
    "oportunidade_id": "op_18271"
  }
}

• event: o nome do acontecimento, em três partes (sistema.objeto.ação). É o que a audiência, a jornada e o Envio para o Meta vão filtrar.
• email e phone: a identidade. Pelo menos um. É o que casa com o lead que o pixel criou — e o telefone precisa do DDI.
• occurred_at: quando aconteceu, não quando foi enviado. Sem isso o evento ganha a hora da chegada, e o reenvio de ontem cai em hoje.
• data: o que só o seu sistema sabe. Vai inteiro para a linha do tempo, e é por ele que o filtro "só o produto X" funciona.

O bloco data é a parte livre do contrato, e é a que decide o valor. CRM que manda só o evento sem o produto entrega um lead que não dá para filtrar.

Autenticação e reentrega

Cada fonte de webhook tem uma chave na URL e uma assinatura HMAC do corpo. Requisição sem assinatura válida é recusada — um endpoint aberto seria uma porta para inventar leads. E o mesmo evento reenviado (o CRM tentou duas vezes, a rede falhou no meio) precisa de uma chave de deduplicação: o id da oportunidade mais a etapa costuma bastar. Sem isso o "respondeu" entra duas vezes e a conversão que vai ao Meta é contada em dobro.

O que vira depois

• Linha do tempo: o evento aparece na ficha da pessoa, ao lado do clique no anúncio e da compra na Hotmart — é o que faz a história ficar inteira.
• Conversão para o Meta: um Envio filtra "crm.opportunity.two_way_interaction" do produto X e manda como evento personalizado pelo CAPI, com a identidade do CRM (100% de telefone).
• Audiência: "respondeu e não recebeu proposta em 3 dias" é uma regra sobre dois eventos do mesmo CRM.
• Pergunta à IA: "quantos leads da campanha Y responderam esta semana" cruza o evento do CRM com a origem que o pixel gravou.

Erros que vimos em produção

1. 01Mandar a hora do envio como occurred_at. Reprocesso em lote põe mil eventos no mesmo minuto.
2. 02Telefone sem DDI. "11 99999-0000" não casa com "+5511999990000" — e o lead vira duplicado.
3. 03Nome do evento diferente do que foi configurado no filtro. O painel do sistema diz "compra_aprovada", o payload diz "order_approved"; o filtro por um nunca vê o outro. Sempre olhar o payload REAL antes de configurar.
4. 04Bloco data vazio. O evento entra, mas não há como separar produto — e o Envio para o Meta manda a conversão do produto errado.

No CrazyLeads a fonte de webhook recebe esse contrato com chave por fonte e assinatura HMAC, extrai a identidade, deduplica por chave, guarda o bloco data inteiro na linha do tempo, e oferece o catálogo de eventos e campos MEDIDO do que chegou — para o Envio, a audiência e a IA filtrarem pelo que existe, não pelo que se supõe.