A chatbot webhook is an HTTPS endpoint that your chatbot platform POSTs a JSON payload to whenever something happens: a visitor starts a conversation, the agent finishes a reply, a lead is captured. Point that endpoint at n8n, Make or Zapier and everything downstream — Slack alerts, spreadsheets, CRM updates, follow-up emails — is automation you already know how to build. On SuperCognit you register the endpoint from the dashboard, choose the events, and every delivery is signed and retried. This guide covers the events that exist, what the payloads look like, the receiver in each tool, and the handful of mistakes that quietly lose data.

The events you can subscribe to

Event names are a public contract: they are added to, never renamed, so an automation built today keeps working. The ones most people use:

Event
Fires when
Typical use
conversation.created
A visitor starts a new conversation with an agent
Count conversations by page or channel; start a session timer
message.created
A message is added, by either side
Full transcript mirroring into your own store
message.completed
The agent finishes generating a reply
Quality review, sentiment scoring, token accounting
lead.captured
The agent captured a qualified lead
Slack alert, spreadsheet row, CRM you run yourself
lead.delivered
The lead reached the connected CRM
Confirm the handoff; fires later than captured, after any retry
lead.failed
Delivery to the CRM was given up
Alert a human — the lead is still in the dashboard and re-sendable
payment.completed
A checkout link sent in chat was paid
Fulfilment, receipts, revenue dashboards
knowledge.source.failed
A website or document re-sync failed
Alert whoever owns the content
product.published / unpublished
An agent or MCP server changed status
Change log, status page
channel.disconnected
WhatsApp or Telegram lost its connection
Page the on-call person before customers notice

An endpoint with an empty event list receives everything. Start narrow — one event, one workflow — and widen once the first recipe is boring.

What a lead payload looks like

{
  "id": "evt_…",                // stable across retries — dedupe on this
  "event": "lead.captured",
  "version": 1,
  "createdAt": "2026-09-10T09:14:02.000Z",
  "workspaceId": "…",           // a receiver may serve several 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": "…" }
  }
}

The fields object carries whatever qualifying answers the agent collected, consent records that the visitor agreed to be contacted, and crm is present only when a CRM is connected. Payloads only ever gain fields; nothing you map today will disappear.

Register the endpoint

01

Create the receiver first

In n8n, Make or Zapier, add a webhook trigger and copy the URL it gives you. It has to accept POST and answer with a 2xx quickly — do the slow work after responding.

02

Add the webhook in the dashboard

Under Settings → Webhooks, add an endpoint, paste the URL and pick the events. Copy the signing secret; you will not build the verification without it. The same registration is available over the REST API for teams that provision from code.

03

Send a test

Start a conversation with your own agent, or capture a test lead. Watch the delivery log in the dashboard: each attempt is recorded with the response status your endpoint returned.

04

Verify the signature before trusting the body

Every delivery carries an x-supercognit-signature header: sha256= followed by the HMAC-SHA256 of the raw request body, keyed with your secret. Compute it, compare in constant time, reject on mismatch. Anyone can POST to a public URL; only the platform can sign.

// Node.js — verify the signature on the RAW body (not the parsed JSON)
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));
}

Receiving in each tool

n8n

Use the Webhook node with method POST and "Respond immediately". Add a Code node right after it to verify the signature with the snippet above — n8n exposes the raw body when you enable it on the node — then branch on the event field with a Switch node. Self-hosted n8n behind your own domain is the tidiest option: your secret and your data stay with you.

Make

Create a Custom webhook, run one test delivery so Make learns the structure, then add a router keyed on event. Make can compute an HMAC in a text function; compare it to the header before the router, and stop the scenario on mismatch.

Zapier

Use Webhooks by Zapier with Catch Hook as the trigger. Zapier parses the JSON for you, which is convenient and also means you need a Code step to reconstruct the raw body for verification; if that is more than you want, restrict the Zap to low-risk recipes such as notifications and keep CRM writes on the native integration.

Retries and idempotency

Deliveries that do not get a 2xx are retried up to five attempts with exponential backoff — one, two, four and eight minutes apart — and every attempt is logged with the response status. The id on the envelope stays the same across all attempts, which is what lets you dedupe: if your endpoint answered slowly and the retry arrived anyway, the second copy has the same id, and you skip it. Answer fast, store the id, do the work afterwards.

Five recipes that pay for the setup

  • lead.captured → Slack message to the sales channel with the contact, the qualifying answers and a link to the transcript.
  • lead.failed → alert to whoever owns the CRM connection, with the lead id to re-send from the dashboard.
  • message.completed → append to a review sheet, then sample ten a week for quality.
  • conversation.created → count by sourceUrl in a dashboard, so you see which pages start conversations.
  • knowledge.source.failed → ticket to the content owner before the agent starts answering from stale pages.

"ChatGPT webhook": why that search finds nothing useful

People searching for a ChatGPT webhook usually mean one of two things. If they built a custom GPT, the answer is that a GPT can call your API through an action, but it does not push you an event when a conversation happens — there is no outbound webhook to subscribe to. If they built a bot on the OpenAI API themselves, the webhook is their own code to write. Either way the feature being looked for is a platform that emits events about conversations and leads. That is what the event catalogue above is.

Mistakes that lose data

  • Doing the slow work before responding. A CRM write that takes twelve seconds times out the delivery, which then retries — and now you have two deals.
  • Verifying the parsed JSON instead of the raw body. Re-serialising changes bytes; the signature will never match.
  • Subscribing to everything on day one. message.created alone can be thousands of events a day; start with the one you will act on.
  • Ignoring lead.failed. The lead is safe in the dashboard, but nobody knows to re-send it unless something tells them.

Webhooks are the part of a chatbot nobody sees and everybody depends on. Register one endpoint, verify one signature, build one recipe, and the rest of your stack starts hearing what your agent is doing.