Webhooks

You've applied for a job. You have two options for finding out whether you got it:

Option A: Call the company every hour and ask "Did you make a decision yet?" This is polling.

Option B: Give them your phone number and say "Call me when you've decided." This is a webhook.

Webhooks flip the communication model entirely. Instead of the client repeatedly asking the server "did anything happen?", the server reaches out and tells you when something happens. No wasted requests. No delays. The moment an event occurs, you know about it.

Stripe uses webhooks to tell your server when a payment succeeds. GitHub uses webhooks to notify your CI/CD pipeline when code is pushed. Shopify, Twilio, Slack, PayPal, virtually every modern API uses webhooks as the primary way to deliver events.

If you've ever integrated with a third-party API, you've almost certainly dealt with webhooks. And if you haven't yet, you will.

A webhook is just an HTTP POST request sent from one server to another when an event occurs. That's it. No special protocol, no persistent connections, no fancy handshakes.

The setup:

1. You register a URL with the event source (e.g., you tell Stripe: "Send payment events to https://myapp.com/api/webhooks/stripe")
2. An event occurs on the source system (e.g., a customer's payment succeeds)
3. The source sends an HTTP POST to your registered URL with a JSON payload describing what happened
4. Your server processes the event and responds with a 200 status code
5. If your server doesn't respond (or responds with an error), the source retries, usually with exponential backoff

The efficiency here: your server does zero work until an event actually happens. No polling, no open connections, no wasted bandwidth. You just sit there waiting for HTTP requests to arrive.