A Practical Guide to Webhooks
HTTP requests one system sends to another when an event happens, such as a payment succeeding or an order shipping, so the receiving system can react immediately.
Marcus Adeyemi
What is at stake
Webhooks connect stores, payment providers and business tools, and unverified or unreliable handlers cause missed orders and security holes.
The playbook
- Verify webhook signatures
- Process events idempotently using event IDs
- Acknowledge quickly and do heavy work in background jobs
- Log received events for troubleshooting
- Monitor failed deliveries in the provider dashboard
Where it goes wrong
Avoid:
- Trusting unverified webhook requests
- Long processing before responding
- Assuming events arrive exactly once and in order
- Exposing webhook endpoints without any authentication
The numbers behind it
| Measure | Figure |
|---|---|
| Verification | providers such as Stripe sign webhook payloads so receivers can verify them |
| Retries | providers retry failed deliveries, so handlers must tolerate duplicates |
| Idempotency | processing the same event twice should have no extra effect |
| Response | handlers should return a 2xx status quickly |
Getting outside help
When to hand it over: Bring in help when orders or payments go missing between systems, or when building integrations with several providers.
Where this comes from
- Stripe Documentation — Receive Stripe events in your webhook endpoint
- OWASP — REST Security Cheat Sheet
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
