Webhook

A webhook therefore works on the push principle: the information is delivered actively as soon as it arises, rather than being collected at the next retrieval. It is precisely this push behaviour that makes webhooks one of the most important building blocks of modern system integration and automation.

The term itself describes the principle quite aptly: a "hook" is a point in the program flow where you can plug in your own code. A webhook moves this plug-in point onto the web: instead of a function in the same program, an external URL is called over the internet. You store an address with the triggering service once, and from then on the service calls this address for every matching event. The programmer Jeff Lindsay coined the term around 2007, and since then the concept has established itself as the de facto standard for event-driven notifications between web services.

Webhook vs polling: push instead of constant asking

To understand why webhooks are so widespread, it is worth comparing them with the classic counter-model, polling. With polling, one system actively asks the other system at fixed intervals whether anything has changed, for example every 30 seconds, every minute or every hour. This approach is easy to implement but has two structural drawbacks: it creates unnecessary load because the vast majority of requests come back empty, and it is always one interval too slow because a change is only noticed at the next retrieval.

The webhook reverses this relationship. It is not the recipient who asks; the sender reports of its own accord, and exactly when there is something to report. This saves resources on both sides and delivers the information almost in real time. The following overview compares the two approaches.

In practice, the two methods are not mutually exclusive. Many robust integrations use webhooks as a fast real-time channel and add occasional polling as a safety net in case individual webhook deliveries are lost.

Webhook vs API: two sides of the same coin

Webhook and API are often confused, but they are complementary concepts. A classic API (more precisely, a request-response API) waits passively until a client makes a request and then responds. The initiative lies with the caller. A webhook reverses this direction: here the system that otherwise provides the API is the active sender, and your own endpoint is the recipient. This is why people occasionally speak of a "reverse API".

A vivid comparison: an API is like a telephone that you call when you want to know something. A webhook is like a notification service that calls you of its own accord as soon as something happens. Both use the same technical basis, HTTP, but differ in who takes the initiative. In reality, the two often work together: a webhook tells you that something has happened, and you then retrieve the full details via the API.

How a webhook is structured technically

Technically, a webhook is pleasingly unspectacular, and that is precisely its strength. When an event occurs, the triggering system sends an HTTP request, as a rule a POST request, to the URL you have stored. The content of this request, the so-called payload, describes the event. Today this payload is almost always written in JSON format.

A typical webhook call for a newly received order could look like this, for example:

POST /webhooks/order HTTP/1.1
Host: your-application.com
Content-Type: application/json
X-Signature: sha256=8f3b2c...

{
  "event": "order.created",
  "id": "ord_10482",
  "customer": "customer@example.com",
  "amount": 149.90,
  "currency": "EUR",
  "timestamp": "2026-06-05T09:14:22Z"
}

Your endpoint receives this request, reads the payload and triggers the appropriate reaction, for example sending an order confirmation, writing the record to the ERP or triggering an internal notification. It is important that your endpoint responds quickly with an HTTP status code in the 2xx range to acknowledge successful receipt. You should move elaborate processing to a background process so that the response to the sender does not run into a timeout.

Typical payload and headers

In addition to the actual JSON body, a webhook usually carries several meaningful HTTP headers. Common ones are a header naming the event type (such as order.created or payment.succeeded), a unique event ID for detecting duplicates and a signature header for verifying authenticity. The event type allows your endpoint to use a single URL for many different events and to react differently depending on the type.

Security: why verification is mandatory

A webhook endpoint is by definition publicly reachable; otherwise the sending service could not call it. But that also makes it reachable for unauthorised parties. Anyone who knows or guesses the URL could send forged requests. That is why the verification of incoming webhooks is not an optional extra but a basic requirement for productive use.

The most widespread mechanism is signature verification via HMAC. Sender and recipient agree on a shared secret once. The sender calculates a cryptographic signature (often HMAC-SHA256) from the payload and this secret and attaches it as a header. Your endpoint recalculates the same signature with the same secret and compares the two values. If they match, it is ensured that the request really comes from the expected sender and was not altered on the way. If they do not match, you discard the request.

• Keep the secret secret: the secret belongs in a secure configuration, never in the source code or the front end.
• Always check the signature: do not process any payload whose signature you have not verified.
• Enforce HTTPS: webhook endpoints should only be reachable via TLS so that the payload does not travel across the network in plain text.
• Take timestamps into account: a timestamp sent along helps to fend off old intercepted requests (replay attacks).

Anyone who follows these basic rules rules out the most common security gaps in webhook processing from the outset.

Retries and idempotency

Webhooks are delivered over the open internet, and deliveries can fail, for example because your server was briefly unreachable. Reputable providers therefore repeat the delivery automatically (retries), usually at increasing intervals over hours or days, until your endpoint returns a success status code. These repetitions are a strength, but they have one consequence: the same event can reach you several times.

The answer to this is idempotency. Your endpoint must be built so that processing the same event several times has the same effect as processing it once. In practice you achieve this by storing the unique event ID supplied and processing each ID only once. If an event that is already known arrives again, you acknowledge receipt but do not carry out the action a second time. This avoids duplicate bookings, duplicate emails or duplicate records.

Typical use cases

Webhooks have become indispensable in today's software landscape. They connect services that would otherwise know nothing about each other and are the backbone of many real-time automations. Some of the most common named examples:

• Stripe sends webhook events such as payment_intent.succeeded or invoice.paid so that your shop can react to successful payments without actively querying the payment status. Many regard Stripe's webhook documentation as the reference for clean webhook design, including signature verification.
• GitHub webhooks notify external systems of events such as a push, an opened pull_request or a new issue, the basis of many CI/CD pipelines and deployment automations.
• Slack incoming webhooks allow messages to be posted to a Slack channel with a simple POST request, a popular way of feeding alerts and status messages to the team automatically.
• Shopify webhooks report events such as orders/create or products/update to connected systems, for example to pass orders directly to an ERP or fulfilment system.

These examples show the common pattern: an event in system A immediately triggers a reaction in system B via a webhook, without a person or a polling cycle having to stand in between.

Webhooks in no-code tools such as n8n, Make and Zapier

Webhooks reach their full impact in combination with no-code and low-code automation platforms. Tools such as n8n, Make and Zapier provide a webhook node that generates a unique receiving URL for you in a few clicks. You store this URL with the triggering service, and every incoming webhook then starts a complete automation workflow, without any server code of your own.

This turns webhooks into the universal trigger for automations: an incoming order, a completed form or a successful payment sets off a chain of steps via webhook, such as enriching data, writing it to another system or sending a notification. Much of the process automation & AI workflows we implement is built on exactly this principle. A practical example is automatic alerting with n8n, where an incoming webhook triggers an immediate notification to the responsible team.

The appeal of this approach is that you use the powerful push principle of webhooks without having to program, secure and run an endpoint yourself; the platform takes care of receipt, signature verification and further processing. For many automations in mid-sized companies, this is the fastest way from an event to a reliable, repeatable reaction.

Frequently asked questions

What is the difference between a webhook and an API?

With a classic API, you actively request data; the initiative lies with you. With a webhook, the other system reports of its own accord as soon as an event occurs. A webhook is therefore a kind of reverse API: instead of asking, you are notified. Both use HTTP and are often combined in practice.

Do I need my own server for webhooks?

Not necessarily. You do have to provide an endpoint that is reachable over the internet, but no-code platforms such as n8n, Make or Zapier supply this endpoint ready-made. You get a receiving URL and can build the processing without any server code of your own.

How do I protect a webhook against misuse?

The most important protection is signature verification via HMAC with a shared secret: you recalculate the signature sent along and discard all requests whose signature does not match. In addition, you should only allow HTTPS, keep the secret safe and fend off replay attacks with a timestamp.

What happens if my endpoint does not accept a webhook?

Reputable providers automatically repeat the delivery over a longer period until your endpoint responds with a success status code. Because the same event can then arrive several times, your endpoint should be idempotent and process each event ID only once.

What is a webhook used for in automation?

In automation platforms, the webhook usually serves as the trigger: an event in a source system, such as an order, a form or a payment, starts a complete workflow via the webhook URL, which then processes data, forwards it or sends notifications.