What are webhooks
When the request comes from outside
Everything you've learned so far follows the same pattern: your app sends a request to an external service, and the service sends a response. Your app asks Stripe "show me this customer's invoices," and Stripe answers.
But sometimes the flow goes the other way. Something happens on Stripe's side (a payment succeeds, a subscription is canceled), and your app needs to know about it. Not five minutes later. Right now.
How does your app find out? Two options.
Option A: your server keeps asking Stripe "did anything change?" every few seconds. Like refreshing a delivery tracking page over and over, hoping for an update.
Option B: you tell Stripe "call me when something happens." Like giving the restaurant your phone number so they text you when your table is ready, instead of calling them every two minutes.
Option A is called polling. Option B is called a webhook. This chapter is about option B.
Polling: the brute-force approach
Polling means your server calls the external service's API on a timer: "Any new payments? No? OK, I'll ask again in 30 seconds."
It works, but most of the time the answer is "nothing changed." Your server is burning requests, bandwidth, and API rate limits for nothing. And if something does happen, you only find out on the next check, not when it actually occurred.
Webhooks: "don't call us, we'll call you"
A webhook flips the direction. Instead of your server asking the external service for updates, the external service calls your server when something happens.
Here's the setup: you give Stripe a URL on your server (called a webhook URL). You say: "whenever a payment succeeds, send a message to this URL." From that point on, Stripe calls your server automatically every time a payment goes through. No polling. No wasted requests. You get the data exactly when it matters.
The key point: webhooks are always about an external service sending data to your app. Stripe tells you about payments. Shopify tells you about orders. It's always an outside system reaching into yours to say "hey, this just happened."
You've seen this pattern before
Webhooks are behind most real-time features you use every day. The pattern is always the same: something happens on an external service, and that service notifies your app.
- Stripe → your app. A customer pays for a subscription. Stripe sends a webhook so your app can instantly unlock the premium features. Without it, the user would pay and see nothing happen until your server checks Stripe later.
- Shopify → your warehouse. A customer places an order on your online store. Shopify fires a webhook to your fulfillment system so packing starts immediately, not the next time someone checks the dashboard.
- Twilio → your support tool. A customer replies to an SMS you sent. Twilio sends the message to your server via webhook so it shows up in your support inbox in real time. Notice the pattern: it's always External Service → Your App. Webhooks are the mechanism external services use to push information into your product the moment something happens on their side.
Polling vs. webhooks side by side
| Polling | Webhooks | |
|---|---|---|
| Who initiates? | Your server asks repeatedly | The external service tells you |
| Timing | You find out on the next check (delayed) | You find out immediately |
| Wasted requests | Many (most checks find nothing new) | Zero (only fires when something happens) |
| Setup | Easy (just call the API on a timer) | Requires registering a webhook URL |
| Analogy | Refreshing the delivery page every 5 min | Getting a push notification |
Polling is simpler to set up, but it doesn't scale. If you're checking 10 services every 30 seconds, that's 20 requests per minute doing nothing useful. Webhooks are more efficient: zero requests until something actually happens, then one notification with all the data you need.
The webhook URL
To receive webhooks, you need to give the external service a URL where it can send messages. This is your webhook URL (sometimes called a webhook endpoint or callback URL).
It looks like any other URL:
https://yourapp.com/webhooks/stripe
When you configure webhooks in Stripe's dashboard (or any service), you paste in this URL and select which events you want to receive. Stripe stores it and sends a POST request to that URL every time one of those events happens.
Your engineering team is the one who sets this up. But as a PM, you'll see this concept come up in integration discussions. When someone says "we need to set up a webhook for payments," they mean: register a URL with Stripe so your server gets notified automatically.
Key takeaways
- Polling means asking "anything new?" on repeat. It works but wastes resources.
- Webhooks flip the model: the service notifies you when something happens.
- You register a webhook URL with the external service. It sends data to that URL automatically.
- Webhooks power real-time features: instant payment confirmations, order updates, deployment triggers.
- You don't need to build webhooks yourself. You need to understand the concept to have productive conversations with your engineering team.