What Is a Webhook? How Two Systems Trigger Each Other Instantly, Explained With a Real Example

Say you run an e-commerce site. A customer enters their card details, Stripe approves the payment — and this happens entirely inside Stripe's infrastructure, with your server having no idea it occurred. How does your system find out? There are two ways: either your system keeps asking Stripe 'did a payment come in, did it, did it?' every few seconds (this is called polling), or Stripe tells you itself the instant it happens. The second approach is called a webhook — and it sits under almost every 'instant' integration on the internet today: a WhatsApp message landing in your CRM within seconds, a code push to GitHub automatically triggering CI/CD, a form submission pinging a Slack channel. They're all the same idea wearing different clothes.

##What Is a Webhook, Really?

A webhook is a system automatically sending an HTTP request (usually a POST) to a URL you've provided, the moment something happens on its side — a payment, a form submission, a code push. It's the technical version of saying 'call me when this happens, here's my number.' Think of it like leaving your phone number with the building doorman instead of walking down every hour to ask if a package arrived — the doorman calls you the moment it shows up. You stop asking; they start telling. This simple idea is what lets most of modern software connect to each other in real time — Stripe, GitHub, Shopify, Twilio, the WhatsApp Business API, Typeform, and basically every serious SaaS product supports webhooks. That's the honest answer to what is a webhook: an event-driven notification mechanism initiated by the other side.

##Webhook vs. Polling an API — What's the Actual Difference

The easiest way to understand a webhook is to compare it to the alternative. With polling, your system asks the other side 'anything new?' at fixed intervals — most of the time the answer is 'no,' which means thousands of wasted requests. With a webhook, the other side calls you only when something actually happened — no wasted questions. It sounds like a small detail, but at scale it directly affects both server cost and how fast you notice an event.

• ▸Latency: with polling, the gap between an event and you noticing it can be seconds to minutes; with a webhook it's usually under a second.
• ▸Server load: polling generates thousands of requests that mostly return 'nothing changed'; a webhook only fires on real events.
• ▸Setup complexity: polling is easy to set up (a scheduled job is enough); a webhook means writing an endpoint and thinking about its security.
• ▸When polling still makes sense: when the other system doesn't support webhooks, or the event is already low-frequency, like a once-a-day sync.

##Common Places Webhooks Show Up

It's easier to grasp webhooks as the mechanism running quietly behind tools you already use, rather than as an abstract concept. A lot of the integrations you rely on daily are built on top of one:

• ▸Stripe/iyzico: updating an order the moment a payment succeeds or fails
• ▸GitHub/GitLab: triggering a CI/CD pipeline automatically on a code push
• ▸Shopify/WooCommerce: notifying a warehouse or accounting system the instant a new order comes in
• ▸Twilio/WhatsApp Business API: dropping an incoming message straight into a CRM or support inbox
• ▸Typeform/Google Forms: creating a lead record automatically when a form is submitted
• ▸Slack/Discord: posting a channel alert when a system hits an error or a key event
• ▸Calendly: adding a booked meeting to a calendar and reminder system automatically

##How a Webhook Actually Works Under the Hood

Behind the scenes there are three pieces: an event source (Stripe, say), an 'endpoint' you write (typically a URL like /webhooks/stripe), and the HTTP request connecting them. When the event happens, the source system sends a POST request to that URL; the body usually carries the event details as JSON — which payment, how much, which customer, what timestamp. Your endpoint receives the request, verifies it, and runs its own business logic: writes to a database, queues a job, notifies another service. Technically, a webhook isn't a different protocol from a normal API call — same HTTP, same JSON. The difference is who initiates it: in a normal API call, you ask; in a webhook, the other side sends.

>Why signature verification matters

Because the endpoint URL is public, in theory anyone could send you a fake 'payment succeeded' request and walk away with a free product. To prevent this, serious services attach a signature to every request — you verify it with your own secret key to confirm the request genuinely came from that service. Stripe's stripe-signature header and GitHub's X-Hub-Signature are concrete examples. A webhook endpoint that processes any request without verifying its signature is a real security hole — the same category of mistake as leaving an API key exposed publicly.

##Webhook or WebSocket? Two Concepts People Mix Up

Both get lumped under 'real-time,' but they do very different jobs. A webhook is a one-off event notification — something happens, a request goes out, the connection closes. A WebSocket is a persistent, two-way connection that stays open; it's what powers messages streaming instantly in a chat app or prices updating continuously on a trading screen. A simple rule of thumb: if the event is infrequent and one-directional, like a payment confirmation or a form submission, a webhook is enough and simpler; if you need continuous, high-frequency, two-way data flow, like live chat, live pricing, or a shared editing screen, you need a WebSocket. Most SaaS integrations actually fall into the webhook camp — which is why you run into webhooks far more often than WebSockets.

##A Real Scenario: How a Payment Webhook Turns Into an Order

Picture running a small e-commerce store. A customer enters their card, Stripe processes the payment — entirely inside Stripe's own infrastructure, with your server none the wiser. The instant the payment is confirmed, Stripe sends a POST request to the URL you registered, say https://yoursite.com/webhooks/stripe, carrying a payment_intent.succeeded event with the payment details. Your endpoint does three things: verifies the signature; marks the matching order as 'paid' in your database; queues a 'prepare this order' task for fulfillment and fires an automatic thank-you email. All of this happens in a second or two — before the customer even sees the 'payment successful' screen. Now, what if a network glitch causes that same webhook request to arrive twice? A well-built system anticipates this — it checks the unique event ID attached to every request, and if it's already processed that ID, it silently ignores the duplicate. This is called idempotency, and in practice almost no webhook integration is safe to run without it. You never once asked Stripe 'did the payment come in?' — Stripe told you, and all you had to build was listening for it correctly.

##What to Watch Out for When Setting Up a Webhook

Setting up a webhook looks like a five-minute job, but a solid setup has a few details that are easy to miss:

• ▸Signature verification: confirm every incoming request genuinely comes from the source you expect, and reject anything unsigned.
• ▸Idempotency: the same event can arrive twice because of a network retry — your system shouldn't process the same payment twice.
• ▸Respond fast: your endpoint should return 200 OK the instant it receives the request, and do the real work in a background queue — otherwise the source system assumes failure and keeps retrying.
• ▸Retries and logging: most services retry a failed webhook a few times, but not forever — you need to log failures somewhere you can check manually.
• ▸Test locally: tools like the Stripe CLI or ngrok let you test a webhook on your own machine before it ever goes live.

##FAQ

>What's the actual difference between a webhook and a normal API call?

In a normal API call, you ask the other side for data — you hold the initiative. With a webhook, the other side holds it: when something happens, they send you a request. Technically both use the same protocol (HTTP) and usually the same format (JSON); the difference is who initiates the request, and when.

>Are webhooks secure — can someone send a fake request?

Not if it's set up carelessly — since the endpoint URL is public, in theory anyone can send a request to it. That's why signature verification should be treated as mandatory; a webhook endpoint that accepts unsigned or incorrectly signed requests is a real security hole. Restricting the endpoint to the source's published IP ranges, where available, adds another layer.

>If my webhook endpoint goes down temporarily, is data lost?

Usually not. Services like Stripe and GitHub retry a failed webhook — anything that doesn't return 200 — at increasing intervals over hours or even days. But that's not a guarantee — some services eventually give up. For anything critical, you should monitor your endpoint's logs and be able to manually reconcile from the source system's own dashboard, like Stripe's 'Events' tab.

>When does a small business or a solo project actually need a webhook?

Whenever you need to react instantly to an event from a third-party service — payments, messaging, forms, a CRM. Creating an order on payment confirmation, dropping a lead into a CRM when a form is submitted, triggering an automatic reply when a message arrives — all of these are webhook problems. If you're only syncing a report once a day, a scheduled job (cron) is probably simpler and enough.

>Do I need a separate server for a webhook, or can I add it to my existing backend?

No, usually not. A webhook is just a route or endpoint you add to your existing backend — you don't need a separate service for it. Once traffic grows large, or hundreds of webhooks arrive at once from multiple sources, it starts to make sense to drop the request straight into a queue and process it with a separate, scalable worker; but for a small-to-medium project, adding one endpoint to your existing backend is more than enough.

A webhook is a small but critical piece of how two systems connect to each other — if you're curious how API integrations actually work, feel free to look through related posts, or reach out via /contact about an integration for your own project.