How it works
You give a service (Stripe, Razorpay, GitHub, a form tool) a URL on your server. When an event occurs, it sends an HTTP POST to that URL with the details as JSON, and your endpoint updates the order, sends the email or starts the build. Payments depend on them: the webhook, not the browser's redirect, is the reliable signal that money arrived.
Because the URL is public, anyone could post to it, so senders sign each request (usually an HMAC with a shared secret) and your code must check that signature. Senders retry when an endpoint fails or is slow, so the same event can arrive twice: reply with a 2xx status quickly, hand slow work to a queue and make handlers idempotent. The Stripe CLI and tunnelling tools forward webhooks to a laptop for testing.
Webhooks pros and cons
Pros
- Instant updates without polling
- Simple: an HTTP endpoint that accepts POST requests
- Works on serverless platforms, since each event is one request
Cons
- Endpoints must verify signatures or they can be faked
- Events can arrive twice, late or out of order
- Harder to test locally without a tunnel or CLI
When to use Webhooks
Pick it when
- Reacting to payments, subscriptions and refunds
- Connecting services, such as Git pushes that trigger deploys
Skip it when
- The receiver is a browser or phone, which cannot expose a public URL (use push or WebSockets)
Webhooks vs the alternatives
Related terms
More in Backend and APIs
Jobs and glue