What is a webhook? Explained with a WhatsApp example
A webhook is an automatic notification one system sends to another the instant an event happens, delivered as an HTTP request to a URL you provide, instead of the receiving system having to repeatedly ask 'has anything changed yet?' It is how a payment gateway, an e-commerce platform or a CRM tells a chatbot platform to act immediately, without any manual checking.
- A webhook pushes an event to you the moment it happens; polling makes you repeatedly ask if anything happened.
- A webhook payload is usually a structured JSON message describing the event and its data.
- A signature (HMAC) on a webhook lets the receiver verify the request genuinely came from the claimed sender, not an impersonator.
- Outbound webhooks push events out of a platform; inbound webhooks receive events into it and can trigger a flow.
- De-duplication matters — a webhook can be delivered more than once, and your system should not act on the same event twice.
The definition
A webhook is a way for one piece of software to automatically notify another the instant something happens, by sending an HTTP request, usually carrying a small JSON message, to a URL the receiving system has registered in advance. Instead of your system having to repeatedly ask a service "did anything change?", the service tells you the moment it does.
The word combines "web" and "hook" — you hook into another system's events over the web, and it calls your hook whenever something relevant happens.
Webhooks are everywhere in modern software even when the term itself stays invisible to the end user: a payment confirming, a form being submitted, a shipment status changing, a calendar invite being accepted, all of these are commonly wired together using webhooks behind the scenes, connecting systems that were never built by the same company.
Push vs poll: the analogy
A webhook is like a doorbell: the moment someone arrives, they press it, and you know instantly. Polling is the alternative: repeatedly walking to the window every few minutes to check if anyone is standing outside, whether or not anyone actually is. Polling wastes effort checking when nothing has changed, and still introduces a delay between the event happening and you noticing it. A webhook has neither problem — it tells you exactly when something happens, and nothing when it doesn't.
Polling is not always wrong to use. Some older or simpler systems only support it, and for very infrequent checks the overhead barely matters. But for anything time-sensitive, like sending a customer their shipping update the moment it actually ships, a webhook is the only approach that avoids either wasted effort or an awkward delay.
Webhook vs polling, side by side
| Webhook (push) | Polling (repeated checking) | |
|---|---|---|
| When you learn about an event | Immediately | Only at your next scheduled check |
| Wasted requests | None, only real events are sent | Many, checking even when nothing changed |
| Setup | Register a URL once | Build a repeating check loop |
Payloads and signatures
The data a webhook delivers is called its payload: typically a JSON object describing what happened ("payment.captured") and relevant details (amount, contact, timestamp). Because a webhook URL is technically reachable by anyone who discovers it, a well-built system signs each payload with a secret key, producing an HMAC signature the receiver can check to confirm the request genuinely came from the claimed sender and was not tampered with in transit. Any inbound webhook worth trusting should verify this signature before acting on the payload. The secret used to generate the signature is agreed between both sides in advance and never travels with the request itself, which is what makes it possible to tell a genuine payload apart from a forged one.
Skipping signature verification is a common shortcut when a webhook integration is first being built and tested, but it should never make it into a live setup. Without it, anyone who discovers or guesses the URL could send a fake event and trigger a real action, such as a payment confirmation message going out for a payment that never actually happened.
A WhatsApp example: inbound vs outbound
Say your e-commerce platform marks an order as "shipped". An outbound webhook from your chatbot platform going the other way might notify your own systems whenever a new WhatsApp message or lead arrives, keeping an external CRM in sync. An inbound webhook works the opposite direction: your e-commerce platform POSTs the "order shipped" event to a unique URL the chatbot platform gave you, which then runs a flow that sends the matched customer a WhatsApp shipping update automatically, and no one has to manually trigger that message.
A payment confirmation follows the same inbound pattern: your payment gateway posts a "payment captured" event, which triggers a WhatsApp receipt or thank-you message to the payer.
A CRM sync is another common outbound example: every time a new WhatsApp lead is captured, an outbound webhook can notify your existing sales CRM immediately, keeping two separate systems reflecting the same up-to-date picture without anyone manually copying information between them.
How it shows up in Convo360
Under Webhooks, Convo360 supports both directions. Outbound webhooks subscribe a URL of yours to platform events (new message, call ended, lead updated), with a delivery log showing every attempt and response. Inbound webhooks give you a unique URL that a third party, a payment page, a form, a shipping tool, POSTs to, which runs a chosen flow to the matched customer, mapping payload fields into flow variables. Payment Triggers for Razorpay are a specialised inbound webhook: connect your Razorpay account, subscribe to payment.captured, and every payment is HMAC-verified and de-duplicated so a payer is never messaged twice for the same transaction. This same webhook mechanism underlies most of Convo360's integrations: Google Sheets updates, CRM sync, and any custom system a business already runs, making it the general-purpose connective layer behind automation that reacts the moment something real happens, rather than on a delay.
Example conversation
Connect your systems with webhooks
Start free in minutes — no code, no credit card. Bring your own AI keys and pay no per-message markup.
Frequently asked questions
Is a webhook the same as an API?
Not quite. An API is something you actively call to ask for data or take an action. A webhook is the reverse — the other system calls you, automatically, the moment an event happens, without you asking.
Why does a webhook need a signature?
Because a webhook URL can technically be reached by anyone who discovers it, a signature (typically HMAC) lets your system verify that an incoming request genuinely came from the claimed sender and was not forged or tampered with.
What is the difference between an inbound and an outbound webhook?
An outbound webhook is one your platform sends out to notify your own systems of an event. An inbound webhook is a URL your platform gives you, which a third-party system posts to in order to trigger an action, such as running a flow.
Can the same webhook event be delivered more than once?
Yes, this can happen due to network retries on the sender's side. A well-built receiver de-duplicates incoming events, so the same payment or message does not trigger the same action twice.
Do I need coding knowledge to use webhooks?
Setting up an outbound webhook subscription or an inbound webhook URL is usually a no-code, form-based step on the platform side. Building the system that sends or receives the payload on your own server does typically need some technical setup.
Related reading
Available across India — see WhatsApp & AI calling automation by state and city.