Skip to content
Chatbotscape
Verified
Webhook· Integration pattern
A webhook is an HTTP callback — a way for one system to notify another in real time when an event happens, by sending an HTTP POST request to a pre-registered URL. Webhooks replace the inefficient pattern of constant polling (constantly asking if anything changed) with event-driven push delivery (systems are notified the moment a change occurs). They are foundational to chatbot integrations: WhatsApp Business API, Meta's Messenger Platform, Stripe, GitHub, and thousands of other systems use webhooks to push events to chatbot platforms and AI agents.
By Chatbotscape Editorial· Methodology· Published 26 May 2026· Updated 26 May 2026

Webhook — Definition, How Webhooks Work, and Examples (2026)

Quick answer~1 min
A webhook is a URL you give to another system; when something happens on their side, they send an HTTP POST to your URL with the event details. It's the standard way services notify each other in real time without constant polling.

What a webhook is

A webhook is a small piece of infrastructure: a URL exposed by one service so other services can send events to it. The receiving system is the "consumer"; the sending system is the "provider." The protocol is plain HTTP — usually POST with a JSON body containing event type, timestamp, and payload data.

The pattern works as follows:

  1. You register a URL. In the provider's settings (Meta's WhatsApp Business API console, Stripe Dashboard, GitHub repository settings), you provide a URL and select which events you want to receive.
  2. The provider stores your URL. It associates the URL with your account and the selected events.
  3. When an event happens on the provider's side (a customer sends a WhatsApp message, a payment succeeds, a Git push lands), the provider makes an HTTP POST to your URL with the event details.
  4. Your URL processes the event. Typically you'd update a database, trigger a workflow, or send a reply.

The key advantage over polling is efficiency and latency. Without webhooks, your chatbot would have to ask "any new messages?" every few seconds — wasting compute and delaying response. With webhooks, the message arrives on your server within milliseconds of being sent.

flowchart LR
 subgraph Polling[API polling - inefficient]
 P1[Your server] -->|every 5 sec: 'any new?'| P2[Provider API]
 P2 -->|usually: 'no'| P1
 P2 -->|occasionally: 'yes, here'| P1
 end
 subgraph Webhooks[Webhooks - event-driven]
 W1[Event happens<br/>WhatsApp msg · payment · git push] -->|HTTP POST<br/>with payload| W2[Your registered URL]
 W2 -->|200 OK| W1
 end

Figure 1. Polling vs webhooks. Polling wastes most requests asking "anything new?" and adds latency between event and reaction. Webhooks deliver events as they happen via a single HTTP POST — at the cost of needing a publicly reachable URL on your side.

How a webhook differs from an API

Both webhooks and APIs use HTTP, so the distinction can be confusing:

  • API (request-response) — your code asks the provider's server for data; the provider responds. The flow starts from your side.
  • Webhook (event-driven) — the provider's server sends data to your code when something happens. The flow starts from the provider's side.

A given integration usually uses both. For example, to build a WhatsApp chatbot:

  • The chatbot platform uses Meta's API to send outbound messages (request-response).
  • The chatbot platform receives inbound messages through a webhook from Meta (event-driven).

The terms "webhook" and "callback URL" are used interchangeably; "event subscription" and "push notification" refer to the same general pattern.

Anatomy of a webhook request

A typical webhook POST body looks roughly like:

{
 "event_id": "evt_abc123",
 "event_type": "message.received",
 "timestamp": "2026-05-26T14:32:11Z",
 "data": {
 "from": "+5511999988877",
 "channel": "whatsapp",
 "message": {
 "type": "text",
 "text": "Hi, do you have the blue dress in size M?"
 }
 }
}

The HTTP request typically also includes:

  • Authentication header — usually an HMAC signature (X-Hub-Signature-256 for Meta, Stripe-Signature for Stripe) that proves the request actually came from the provider. Always verify this.
  • Idempotency key — an ID you use to deduplicate retried events. Providers often retry on network failures.
  • Content-Type — almost always application/json.

Webhooks in chatbot platforms

Chatbot platforms use webhooks heavily, often in multiple directions:

Incoming events the platform consumes:

  • New WhatsApp message from Meta
  • Instagram DM from Meta
  • Facebook Messenger message from Meta
  • TikTok DM (where supported)
  • SMS from Twilio / providers
  • Form submission from a website widget
  • Shopify order, Stripe payment, and other commerce events

Outgoing webhooks the platform sends:

  • Notify a CRM that a lead was captured
  • Update a Google Sheet when a contact subscribes
  • Trigger a Zapier / Make workflow on a custom event
  • Call a customer's own backend for real-time data lookup during a chat flow

Manychat, SendPulse, Botpress, and most chatbot builders expose "webhook" nodes inside their flow builders — you drop a node, configure the URL, choose what data to send, and the bot calls your server during a conversation.

Security: verifying webhooks

Anyone could send a POST to your webhook URL — including attackers trying to impersonate the provider. Always verify the request actually came from the provider. The standard pattern is HMAC signing:

  1. The provider knows a shared secret (you set it up in their dashboard).
  2. The provider computes an HMAC of the request body using that secret and puts the result in a header (e.g., X-Hub-Signature-256).
  3. Your code computes the same HMAC and compares. If it matches, the request is authentic.

Other security practices:

  • Use HTTPS only. Plain HTTP webhooks leak data in transit.
  • Allow only the provider's IP ranges (when published).
  • Implement idempotency. Providers may retry; deduplicate by event ID.
  • Respond with 2xx within seconds. Most providers retry if you don't acknowledge quickly. Acknowledge fast, process asynchronously.

Webhook examples in practice

WhatsApp message received. A customer messages your business's WhatsApp number. Meta's WhatsApp Cloud API sends a POST to the webhook URL you registered. Your chatbot platform reads the message and either replies automatically or routes to a human agent.

Stripe payment succeeded. A customer pays $99 for your product. Stripe sends a payment_intent.succeeded webhook. Your bot's "order confirmation" flow runs, sending a thank-you message via WhatsApp and updating the customer's CRM record.

Bot triggers a CRM update. A user finishes a lead-qualification flow in Manychat. Manychat sends an outbound webhook to HubSpot's API endpoint with the captured data. The lead appears in HubSpot within seconds.

Cross-platform automation. A bot wants real-time inventory data. Mid-conversation, it calls a webhook to the customer's e-commerce backend, gets stock levels, and continues the flow with accurate availability.

Limitations and failure modes

  • No guaranteed delivery. If your server is down, providers retry for some time but eventually give up. Critical event flows need reconciliation logic (poll periodically for anything missed).
  • Order not guaranteed. Event A may arrive after event B even if A happened first. Use timestamps in payload, not arrival order.
  • Network timeouts. Slow webhook handlers cause providers to retry, which produces duplicates. Always respond 200 OK fast.
  • Signature rotation. Secrets rotate over time; build your code to support multiple valid secrets during transitions.
  • AI agent — agents often use webhooks to receive triggers and dispatch actions.

FAQ

Is a webhook the same as an API endpoint?

Technically, a webhook IS an API endpoint — just one that's called by an external system, not by your own code. The distinction is direction-of-call (provider → you) rather than technical mechanism.

Do I need a server to receive webhooks?

Yes. Webhooks need a publicly-reachable URL. Most SMBs use either: (a) their chatbot platform's built-in webhook receiver (Manychat, SendPulse, etc. handle this automatically); (b) workflow tools like Zapier / Make which provide webhook URLs you can paste into vendor settings; (c) a custom backend (Node.js, Python Flask, Ruby) hosted on Render, Vercel, Cloudflare Workers, or similar.

Can webhooks fail?

Yes — and they will. Providers typically retry with exponential backoff: try after 1 min, 5 min, 30 min, etc. for some hours then stop. Critical flows should have a reconciliation poll to catch missed events.

What's the difference between webhook and event stream?

Webhooks are individual HTTP POSTs for event. Event streams (Server-Sent Events, WebSockets, Kafka) are long-lived connections that deliver events continuously. Webhooks are simpler and more widely supported; event streams have lower latency and higher throughput. Most SMB chatbot use cases use webhooks.

How do I test webhooks during development?

Tunneling tools: ngrok, Cloudflare Tunnel, and Tailscale Funnel expose your local development server to the public internet with a temporary HTTPS URL. Configure the provider to send to that URL while you debug.

Sources