Cómo enviar las conversaciones y los leads de tu chatbot a un webhook (n8n, Make, Zapier)

Un webhook de chatbot es un endpoint HTTPS al que tu plataforma de chatbot envía un payload JSON por POST cada vez que ocurre algo: un visitante inicia una conversación, el agente termina una respuesta, se capta un lead. Apunta ese endpoint a n8n, Make o Zapier y todo lo que viene después — alertas en Slack, hojas de cálculo, actualizaciones del CRM, correos de seguimiento — es automatización que ya sabes construir. En SuperCognit registras el endpoint desde el panel, eliges los eventos, y cada entrega va firmada y se reintenta. Esta guía cubre los eventos que existen, qué aspecto tienen los payloads, el receptor en cada herramienta y el puñado de errores que pierden datos sin hacer ruido.

Los eventos a los que puedes suscribirte

Los nombres de los eventos son un contrato público: se añaden, nunca se renombran, así que una automatización construida hoy sigue funcionando. Los que más gente usa:

Un endpoint con la lista de eventos vacía lo recibe todo. Empieza estrecho — un evento, un flujo — y amplía cuando la primera receta ya sea aburrida.

Qué aspecto tiene el payload de un lead

{
  "id": "evt_…",                // estable entre reintentos — deduplica por este campo
  "event": "lead.captured",
  "version": 1,
  "createdAt": "2026-09-10T09:14:02.000Z",
  "workspaceId": "…",           // un receptor puede servir a varios espacios de trabajo
  "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": "…" }
  }
}

El objeto fields lleva las respuestas de cualificación que haya recogido el agente, consent registra que el visitante aceptó que se le contacte, y crm solo aparece cuando hay un CRM conectado. Los payloads solo ganan campos; nada de lo que mapees hoy va a desaparecer.

Registrar el endpoint

// Node.js — verifica la firma sobre el cuerpo BRUTO (no el JSON parseado)
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));
}

Recibirlos en cada herramienta

n8n

Usa el nodo Webhook con método POST y "Respond immediately". Añade un nodo Code justo después para verificar la firma con el fragmento de arriba — n8n expone el cuerpo bruto cuando lo activas en el nodo — y después ramifica por el campo event con un nodo Switch. Un n8n autoalojado detrás de tu propio dominio es la opción más limpia: tu secreto y tus datos se quedan contigo.

Make

Crea un Custom webhook, ejecuta una entrega de prueba para que Make aprenda la estructura y después añade un router por event. Make puede calcular un HMAC en una función de texto; compáralo con la cabecera antes del router y detén el escenario si no coincide.

Zapier

Usa Webhooks by Zapier con Catch Hook como disparador. Zapier parsea el JSON por ti, lo que es cómodo y también significa que necesitas un paso Code para reconstruir el cuerpo bruto de cara a la verificación; si eso es más de lo que quieres, limita el Zap a recetas de bajo riesgo como notificaciones y deja las escrituras en el CRM en la integración nativa.

Reintentos e idempotencia

Las entregas que no reciben un 2xx se reintentan hasta cinco intentos con retroceso exponencial — a uno, dos, cuatro y ocho minutos de distancia — y cada intento queda registrado con el código de respuesta. El id del sobre se mantiene igual en todos los intentos, y eso es lo que te permite deduplicar: si tu endpoint respondió despacio y el reintento llegó de todos modos, la segunda copia tiene el mismo id, y la saltas. Responde rápido, guarda el id, haz el trabajo después.

Cinco recetas que amortizan la configuración

• lead.captured → mensaje en Slack al canal de ventas con el contacto, las respuestas de cualificación y un enlace a la transcripción.
• lead.failed → alerta a quien sea responsable de la conexión con el CRM, con el id del lead para reenviarlo desde el panel.
• message.completed → añadir a una hoja de revisión y muestrear diez a la semana para controlar la calidad.
• conversation.created → contar por sourceUrl en un panel, para ver qué páginas inician conversaciones.
• knowledge.source.failed → ticket al responsable del contenido antes de que el agente empiece a responder desde páginas obsoletas.

"Webhook de ChatGPT": por qué esa búsqueda no encuentra nada útil

Quien busca un webhook de ChatGPT suele querer decir una de dos cosas. Si ha construido un GPT personalizado, la respuesta es que un GPT puede llamar a tu API mediante una acción, pero no te envía un evento cuando ocurre una conversación — no hay ningún webhook saliente al que suscribirse. Si ha construido un bot sobre la API de OpenAI por su cuenta, el webhook es código que le toca escribir. En cualquiera de los dos casos, la función que se busca es una plataforma que emita eventos sobre conversaciones y leads. Eso es el catálogo de eventos de arriba.

Errores que pierden datos

• Hacer el trabajo lento antes de responder. Una escritura en el CRM que tarda doce segundos hace que la entrega expire, se reintenta — y ahora tienes dos oportunidades.
• Verificar el JSON parseado en lugar del cuerpo bruto. Volver a serializar cambia los bytes; la firma nunca coincidirá.
• Suscribirse a todo el primer día. Solo message.created puede ser miles de eventos al día; empieza por el que vas a usar.
• Ignorar lead.failed. El lead está a salvo en el panel, pero nadie sabe que hay que reenviarlo si nada se lo dice.

Los webhooks son la parte de un chatbot que nadie ve y de la que todo el mundo depende. Registra un endpoint, verifica una firma, construye una receta, y el resto de tu stack empieza a enterarse de lo que hace tu agente.