What Is a Webhook?

A webhook is an automatic note from one app to another, sent at the moment an event occurs. A customer pays an invoice, and the billing app fires a short note to your accounting tool. That note is the webhook.

The name sounds technical, but the idea is plain. Instead of you checking an app over and over for news, the app tells you.

The parts of the idea

One technical source calls webhooks "user-defined HTTP callbacks"¹. Each word in that phrase has a plain meaning.

• HTTP is the same system browsers use to load web pages. A webhook rides on it.
• Callback means "call me back when this happens."
• User-defined means you choose where the call goes and which events you care about.

So a webhook is a call-back, over the web, to an address you picked. When the event occurs, the app that owns it sends a web request to that address¹.

What "supports webhooks" means in practice

When an app lists webhook support, it usually means you can give it a web address and tell it which events to report. GitHub describes the setup as a URL plus a list of events to follow².

After that, data about each matching event is delivered to your server on its own². You sign up for an event a single time, when you create the webhook, and the app does the rest².

The steps, in order

1. You pick an address that can receive messages. This is called the endpoint, or the webhook URL.
2. You enter that address in the sending app's settings.
3. You choose which events should trigger a message.
4. An event happens, such as a new order.
5. The sending app pushes a request to your address.
6. Your system reads the request and does something with it, such as adding a row to a sheet.

Who runs which side

Two systems are involved, and each has a job.

The sender is the app where the event happens. It decides when to fire and what to put in the message.

The receiver is the system you point it at. It could be your own server, or an automation service that connects apps without code. The receiver has to be reachable from the internet. Stripe, for one, says registered webhook endpoints must be publicly accessible HTTPS URLs³.

That last point matters for small teams. A tool running on one laptop behind a home router usually can't be reached by an outside app. The address has to be public.

Why apps use them

Webhooks ride on ordinary web traffic, so a web service can take them on without new equipment or setup on its side¹. Stripe says it pushes real-time data to your endpoint when events happen in your account³. The same pattern shows up across payment, shop, support and code tools.

What a webhook is not

A webhook isn't a file you download or a report you schedule. It also isn't a two-way chat between apps. It's one message per event, in one direction. A sender may retry, though, so the same event can arrive more than once. Stripe warns that the same event can sometimes reach an endpoint twice³.

It doesn't do anything by itself, either. The sending app only reports the event. Whatever happens next depends on the system that receives it.

The next pages cover how webhooks differ from polling and what sits inside a request.