Everything so far has worked one way: YOU send a request, the server answers. A webhook flips that around. Instead of you repeatedly asking "has anything changed yet?", the server calls YOU the moment something happens. The classic line for it is: "Don't call us — we'll call you."
Polling vs webhooks
Imagine you are waiting for a payment to complete. Without webhooks you poll: every minute you send "is it paid yet?", mostly getting back "no" — wasting requests and still learning the answer up to a minute late. With a webhook you register once, then sit back; the instant the payment succeeds, the provider sends the news straight to you.
| Approach | How it works | Downside |
|---|---|---|
| Polling | You ask "any updates?" on a repeating timer. | Wasteful and slow — most calls return nothing, and you find out late. |
| Webhook | The server pushes the update to you the moment it happens. | You must run a URL that is always reachable to receive it. |
How a webhook works
- You give the provider a callback URL — a public web address you control, e.g. https://your-app.example.com/hooks/payments.
- You tell it which events you care about (payment succeeded, order shipped, form submitted...).
- When that event happens, the provider sends an HTTP POST to your URL, with a JSON body describing what happened.
- Your endpoint reads the JSON, does its work (update a sheet, send an email, start a workflow), and replies 200 OK to confirm it received the message.
So a webhook is just a normal HTTP request — the same method, headers, and JSON body you already know — except now your app is the server receiving it, not the client sending it.
POST /hooks/payments HTTP/1.1
Content-Type: application/json
{
"event": "payment.succeeded",
"id": "evt_1024",
"data": { "order_id": "A-1001", "amount": 15000, "currency": "INR" },
"created_at": "2026-07-07T10:30:00Z"
}Why webhooks matter for automation
- Real-time — your workflow reacts the instant something happens, not on the next scheduled check.
- Efficient — no endless "anything new?" polling; the provider only contacts you when there is real news.
- Event-driven — a webhook is the trigger that starts most automations: "when a payment arrives, do X", "when a form is submitted, do Y". It is exactly how the "trigger" step in automation tools works underneath.
Almost every service you will automate offers them: a payment gateway fires one when money is received, a form tool when someone submits, a store when an order ships, a code host when someone pushes. Learn the pattern once and you recognise it everywhere.
Two things that make webhooks safe and reliable
Because your callback URL is public, anyone could send a fake POST to it. And because networks fail, the same event might arrive twice. Two habits handle both:
- Verify the sender. Reputable providers sign each webhook — they include a signature header computed with a shared secret. You recompute it and check it matches before trusting the payload (the HMAC idea from the auth lessons, applied in reverse).
- Expect duplicates. A provider that does not get a quick 200 will retry, so the same event can land more than once. Use the event's unique id to skip ones you have already processed — this is called idempotency.
Tip · Golden rule — reply 200 fast, then do the slow work. Read the payload, immediately acknowledge with 200 OK, and handle the heavy processing afterwards. If you do everything before replying, the provider may time out and resend, giving you duplicates.
One practical requirement: your endpoint has to be reachable from the internet over HTTPS. To make normal API calls your machine only needs to send outbound requests; to receive webhooks it must also accept an incoming one — a public URL, a cloud function, or an automation tool's built-in webhook trigger.