What is a webhook?

July 23, 2026 · 6 min read

A webhook is one of the simplest ideas in web development, buried under a lot of jargon: instead of you asking a service “anything new?” over and over, the service calls you the moment something happens. This guide covers everything that matters in practice.

The one-sentence definition

A webhook is an HTTP POST request that one system sends to a URL you provide, at the moment an event occurs. That's it. No special protocol, no SDK, no magic – the same HTTP your browser speaks.

The name is misleading: nothing “hooks” into the web. Think of it as a callback for the internet, or as some people put it, a reverse API – you're not calling them, they're calling you.

How it works, step by step

You register a URL at the sending service (“Payload URL”, “Webhook URL”, “Endpoint”). This is a normal HTTPS address that belongs to you.
Something happens – an order is placed, a build fails, a payment succeeds.
The service sends an HTTP POST to your URL, usually with a JSON body describing the event.
Your side answers with a status code. 2xx means “got it”; anything else usually triggers a retry.

Webhook vs. API: what's the difference?

Both speak HTTP, the direction is reversed. With an API you make the request and get an answer. With a webhook the service makes the request and you answer. That's why a webhook needs a publicly reachable URL, while an API call works from anywhere.

In practice they complement each other: the webhook tells you that an order arrived; if you need the full order, you call the API.

Webhook vs. polling: why webhooks won

Polling means asking every minute: “anything new?” It works, but it's wasteful (99 % of requests answer “no”), slow (up to a minute of delay) and it burns rate limits. A webhook fires exactly once, exactly when needed, with zero requests in between. The trade-off: your endpoint must be reachable and available at that moment – which is why retries exist.

What's inside a webhook?

Three things matter: the method (almost always POST), the headers (content type, often a signature) and the body – the payload. A minimal example:

POST /your-endpoint HTTP/1.1
Host: api.example.com
Content-Type: application/json
X-Signature: t=1690000000,v1=5257a869e7…

{"event":"order.created","id":"ord_1042","amount":4999,"currency":"EUR"}

Payload structures differ wildly between providers – the payload guide shows the common patterns and how to read them.

The four things beginners get wrong

Answering slowly. Do the work asynchronously and answer 2xx immediately – many providers time out after a few seconds.
Ignoring duplicates. Retries mean the same event can arrive twice. Handle it idempotently.
Trusting the sender. Anyone who knows your URL can post to it – verify signatures.
Returning the wrong status code. 4xx often means “never retry”, 5xx means “try again” – status code guide.

How do I receive a webhook without a server?

Classically you'd need a public HTTPS endpoint – a server, a cloud function, a tunnel. But if the goal is simply to know that something happened, a ready-made endpoint is enough: Webhooky gives you a personal URL, and every POST to it becomes a push notification on your phone – with its own sound per event type. Install (Android / iOS), copy the URL, paste it into the sending service. That's the entire setup.

Keep reading

Get Webhooky

Free for your first 100 notifications – set up your endpoint in two minutes.