What is a webhook?

A webhook is an HTTP callback. Instead of your application repeatedly asking a service "has anything changed yet?" — which is what polling does — the service sends an HTTP POST request to a URL you control as soon as something happens. The body of that request describes the event.

The pattern is sometimes called "reverse API" or "push API," but those terms predate the word "webhook," which Jeff Lindsay coined in 2007. The shape is: you register a URL with the source system, the source system POSTs JSON (usually) to that URL whenever a relevant event fires, and your handler responds with HTTP 200 to confirm receipt.

Webhooks are how Stripe tells your server a payment succeeded, how GitHub tells your CI a commit landed, how Shopify tells your fulfillment system an order was placed. They replace the alternative — your server hammering Stripe's API every 30 seconds asking "did anything happen?" — which is wasteful, slow, and rate-limit-prone.

Three things define a webhook in practice. First, directionality: the source initiates, your endpoint receives. Second, the URL is yours: you publish a public HTTPS URL, the source dials it. Third, the contract is the payload shape plus the headers: the source documents what JSON fields and what headers (signature, event ID, timestamp) it will send, and your handler parses accordingly.

What makes webhooks operationally tricky is that they are unsolicited inbound HTTP from someone else's server, on a URL you must keep online forever. They have to be authenticated (signature verification), idempotent (the same event may arrive multiple times because of retries), fast (most providers timeout in 3-30 seconds), and observable (when one fails at 2am, you need to know which one and why). The rest of this glossary covers those concerns.