A webhook is a user-defined HTTP callback: instead of a client repeatedly polling a server to ask whether something has happened, the client registers an HTTPS endpoint and the server pushes a request to that endpoint the moment an event occurs. It is often described as a “reverse API,” because the roles flip — the provider becomes the HTTP client and your application becomes the server receiving the call. Stripe’s documentation frames it directly: “After you register a webhook endpoint, Stripe can push real-time event data to your application’s webhook endpoint when events happen in your Stripe account.”
The mechanics are deliberately simple, which is much of the appeal. The provider sends an HTTP POST to the registered URL, typically carrying a JSON payload that describes the event (a payment succeeding, a charge being disputed, a repository being pushed to). The receiving application parses the payload and reacts. Because webhooks ride on ordinary HTTP, any web server can receive them without special protocols or persistent connections.
Trust is the central problem a webhook receiver must solve, because the endpoint is public and anyone could POST to it. Stripe’s docs warn that “without verification, an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders, granting account access, or modifying records.” The standard defense is signature verification: the provider includes a signature header computed as an HMAC (Stripe uses HMAC-SHA256) over the timestamp and raw payload, keyed with a shared signing secret. The receiver recomputes the signature and compares it with a constant-time comparison, rejecting anything that does not match.
Delivery is best-effort, so providers retry. Stripe attempts delivery for up to three days in live mode with exponential backoff, and events can be resent manually for a window afterward. Retries make webhooks reliable, but they also mean the same event can arrive more than once. Receivers must therefore be idempotent — processing the same event twice should have the same effect as processing it once, usually by recording the event identifier and skipping duplicates.
Webhooks became the connective tissue of the modern software-as-a-service ecosystem. Payment processors, version-control hosts, messaging platforms, and countless other services expose them so that customers can react to events without building polling infrastructure. They are, in effect, the event-driven integration pattern applied at the boundary between independent companies’ systems, turning a request-response API into a push-based stream of notifications.