Como enviar conversas e leads de um chatbot para um webhook (n8n, Make, Zapier)

Um webhook de chatbot é um endpoint HTTPS para onde a plataforma do teu chatbot faz POST de um payload JSON sempre que algo acontece: um visitante inicia uma conversa, o agente termina uma resposta, um lead é captado. Aponta esse endpoint ao n8n, ao Make ou ao Zapier e tudo o que vem a seguir — alertas no Slack, folhas de cálculo, atualizações no CRM, e-mails de seguimento — é automação que já sabes construir. No SuperCognit registas o endpoint a partir do painel, escolhes os eventos, e cada entrega é assinada e reenviada em caso de falha. Este guia cobre os eventos que existem, o aspeto dos payloads, o recetor em cada ferramenta e a mão-cheia de erros que perdem dados em silêncio.

Os eventos que podes subscrever

Os nomes dos eventos são um contrato público: acrescentam-se, nunca se renomeiam, por isso uma automação construída hoje continua a funcionar. Os que mais gente usa:

Um endpoint com a lista de eventos vazia recebe tudo. Começa estreito — um evento, um fluxo — e alarga quando a primeira receita se tornar aborrecida.

O aspeto de um payload de lead

{
  "id": "evt_…",                // estável entre reenvios — desduplica por aqui
  "event": "lead.captured",
  "version": 1,
  "createdAt": "2026-09-10T09:14:02.000Z",
  "workspaceId": "…",           // um recetor pode servir vários workspaces
  "data": {
    "leadId": "…",
    "productId": "…",
    "sessionId": "…",
    "agent": "Showroom assistant",
    "contact": { "name": "Ana Silva", "email": "ana@example.com", "phone": null },
    "fields": { "budget": "20k" },
    "consent": true,
    "sourceUrl": "https://acme.com/pricing",
    "status": "pending",
    "crm": { "provider": "pipedrive", "leadId": "…", "url": "…" }
  }
}

O objeto fields transporta as respostas de qualificação que o agente recolheu, consent regista que o visitante aceitou ser contactado, e crm só está presente quando há um CRM ligado. Os payloads só ganham campos; nada do que mapeares hoje vai desaparecer.

Registar o endpoint

// Node.js — verifica a assinatura no corpo BRUTO (não no JSON já analisado)
import { createHmac, timingSafeEqual } from "node:crypto";

export function verify(rawBody, header, secret) {
  const expected = "sha256=" + createHmac("sha256", secret).update(rawBody).digest("hex");
  return expected.length === header.length && timingSafeEqual(Buffer.from(expected), Buffer.from(header));
}

Receber em cada ferramenta

n8n

Usa o nó Webhook com o método POST e "Respond immediately". Adiciona um nó Code logo a seguir para verificar a assinatura com o excerto acima — o n8n expõe o corpo bruto quando o ativas no nó — e depois ramifica pelo campo event com um nó Switch. Um n8n auto-alojado no teu próprio domínio é a opção mais limpa: o teu segredo e os teus dados ficam contigo.

Make

Cria um Custom webhook, corre uma entrega de teste para o Make aprender a estrutura, e depois adiciona um router com chave em event. O Make consegue calcular um HMAC numa função de texto; compara-o com o cabeçalho antes do router e pára o cenário se não bater.

Zapier

Usa o Webhooks by Zapier com Catch Hook como trigger. O Zapier analisa o JSON por ti, o que é conveniente e também significa que precisas de um passo Code para reconstruir o corpo bruto para a verificação; se isso for mais do que queres, limita o Zap a receitas de baixo risco como notificações e mantém as escritas no CRM na integração nativa.

Reenvios e idempotência

As entregas que não recebem um 2xx são reenviadas até cinco tentativas com recuo exponencial — um, dois, quatro e oito minutos de intervalo — e cada tentativa fica registada com o estado da resposta. O id no envelope mantém-se igual em todas as tentativas, e é isso que te permite desduplicar: se o teu endpoint respondeu devagar e o reenvio chegou na mesma, a segunda cópia tem o mesmo id, e ignora-la. Responde depressa, guarda o id, faz o trabalho a seguir.

Cinco receitas que pagam a configuração

• lead.captured → mensagem no Slack para o canal de vendas com o contacto, as respostas de qualificação e um link para a transcrição.
• lead.failed → alerta a quem é dono da ligação ao CRM, com o id do lead para reenviar a partir do painel.
• message.completed → acrescentar a uma folha de revisão, e depois amostrar dez por semana para qualidade.
• conversation.created → contar por sourceUrl num dashboard, para veres que páginas iniciam conversas.
• knowledge.source.failed → ticket para o dono do conteúdo antes de o agente começar a responder a partir de páginas desatualizadas.

"Webhook do ChatGPT": porque é que essa pesquisa não encontra nada útil

Quem pesquisa por um webhook do ChatGPT costuma querer dizer uma de duas coisas. Se construiu um GPT personalizado, a resposta é que um GPT pode chamar a tua API através de uma action, mas não te envia um evento quando uma conversa acontece — não há webhook de saída para subscrever. Se construiu um bot sobre a API da OpenAI por conta própria, o webhook é código dele para escrever. De qualquer forma, a funcionalidade que se procura é uma plataforma que emita eventos sobre conversas e leads. É isso que o catálogo de eventos acima é.

Erros que perdem dados

• Fazer o trabalho lento antes de responder. Uma escrita no CRM que demora doze segundos esgota o tempo da entrega, que depois é reenviada — e agora tens dois negócios.
• Verificar o JSON analisado em vez do corpo bruto. Voltar a serializar muda os bytes; a assinatura nunca vai bater.
• Subscrever tudo no primeiro dia. Só o message.created pode ser milhares de eventos por dia; começa pelo que vais mesmo usar.
• Ignorar o lead.failed. O lead está a salvo no painel, mas ninguém sabe que deve reenviá-lo a menos que algo o diga.

Os webhooks são a parte de um chatbot que ninguém vê e de que toda a gente depende. Regista um endpoint, verifica uma assinatura, constrói uma receita, e o resto da tua stack começa a ouvir o que o teu agente está a fazer.