Backend
Webhooks
APIs in reverse: instead of the client polling for changes, the provider POSTs an event to a URL you register the moment something happens. They power payment confirmations, CI triggers and most automation platforms. The hard parts are on the receiving end — verify signatures, respond fast, and treat duplicate deliveries as normal.
Purpose
A webhook inverts the usual API relationship: you give a provider a URL, and it calls you — an HTTP POST carrying the event — when something you care about happens. It exists to replace polling: instead of asking "anything new?" every few seconds, the news arrives the moment it is made, cheaper for both sides and far fresher.
When to Use It
Payment events (Stripe confirming a charge), source-control events (a push triggering CI), messaging callbacks, and gluing SaaS products together — automation tools like n8n and Make are essentially webhook routers. Any time a third party owns the data and you need to react to changes, a webhook is the idiomatic answer.
They are the wrong tool when you need the full history (poll a list endpoint or consume an event log instead) or guaranteed ordering — webhooks arrive when they arrive.
Trade-offs
Delivery is at-least-once at best: providers retry on failure, so duplicates are a feature, not a bug, and ordering is not promised. Your endpoint is a public door — anyone can POST to it — so authenticity must be proven per request. And a slow handler causes provider timeouts and retry storms, which is how one bug becomes a flood.
Implementation
Verify the HMAC signature (e.g. Stripe-Signature, X-Hub-Signature-256) before trusting a byte. Return 2xx immediately and do the real work asynchronously — push the payload onto a queue. Deduplicate by event ID, tolerate out-of-order arrival, and log raw events so you can replay them after a bug fix.