Webhook

A webhook is an automated message that one application sends to another the instant a specific event happens. Instead of an app repeatedly asking a service whether anything new has occurred, the service takes the initiative and pushes a notification the moment there is something to report. A common way to describe it is a reverse API call: with a normal API you request data when you want it, but with a webhook the data comes to you, unprompted, as soon as the triggering event fires.

Mechanically, a webhook is delivered as an HTTP request, almost always a POST, sent to a URL that the receiving application has published in advance. That URL is the endpoint, sometimes called the callback address. When the source system detects an event, say a payment clears, a form is submitted, or a customer signs up, it packages details about that event, usually as JSON, and sends them to the configured endpoint. The receiving application then runs whatever logic it wants: updating a database, sending a confirmation email, posting a message to a team chat, or kicking off another process. Setup is typically a matter of registering your endpoint URL in the source system's settings and telling it which events you care about. Because delivery happens over the open web, robust webhooks also include a way to verify that a request genuinely came from the expected source, often a shared secret or a signature the receiver can check.

The term combines web with hook, in the sense of a point where one system can latch onto another and be notified. It was coined by Jeff Lindsay around 2007, capturing the idea of hooking your own code into events happening elsewhere on the web. The concept spread quickly because it fit the growing world of connected online services that needed to react to each other in real time.

For a business, webhooks are the connective tissue that makes software feel instant and automated. They let separate tools work together without manual effort: an order in a store can immediately update inventory, notify shipping, and alert the finance system, all within seconds and without anyone lifting a finger. This real time flow reduces delays, cuts out repetitive manual data entry, and enables the kind of automation that scales, whether that is triggering a marketing sequence when someone subscribes or logging support tickets the moment a customer writes in. Compared to constantly polling a service for changes, webhooks are far more efficient, because messages travel only when there is actually something to say.

The main nuances involve reliability and security. Since a webhook is a single push, the receiving endpoint must be available when the message arrives, so well designed systems retry failed deliveries and receivers acknowledge success quickly. Receivers should also handle the possibility of duplicate deliveries gracefully, treating repeated events as idempotent. On security, because anyone who learns the endpoint could send fake requests, verifying the signature or secret is essential. Webhooks sit alongside related building blocks: they usually carry JSON payloads, they complement traditional APIs rather than replacing them, and they fit naturally into serverless and integration architectures where small pieces of code respond to events on demand.