What Is a Webhook? A Plain-English Guide (2026)
You have almost certainly used a webhook today without knowing it. When a payment lands in your inbox the second a customer checks out, or a chat tool pings your team the instant someone fills a form, a webhook is doing the work. A webhook is a small, automatic message that one app sends to another the moment something happens, so nothing has to sit and wait or keep asking "is it done yet?" This guide explains what a webhook actually is, how it differs from an API, how one fires step by step, the most common uses, and how to receive and secure one safely, all in plain language you can act on.
The short version
A webhook is an app's way of saying "this just happened" by sending an instant message to a web address you control. It is push, not pull, so your system reacts in real time instead of polling for changes. Set one up by giving a service your endpoint URL, then verify every incoming request before you trust it.
What is a webhook, exactly?
A webhook is an automated notification sent from one application to another when a specific event occurs. The sending app packages up a little bundle of data about the event, usually as JSON, and delivers it by making an HTTP request to a URL that you provide in advance. That URL is your endpoint, a page on your server whose only job is to listen for these messages and do something useful when one arrives.
People call webhooks "reverse APIs" for a reason. With a normal API, you are the one asking for information. With a webhook, the information comes to you the moment it is ready, unprompted. Think of it like the difference between refreshing a tracking page every few minutes and getting a text the second your package is delivered. The text is the webhook, and it saves everyone the trouble of constantly checking.
Webhook vs API vs polling
These three terms get tangled together, so here is the honest side by side. They are not competitors so much as different tools for different moments.
| What matters | Webhook | API call | Polling |
|---|---|---|---|
| Who starts it | The sending app | You do | You do, on a timer |
| Direction | Push to you | Pull from them | Repeated pull |
| Timing | Instant | On demand | Delayed by interval |
| Wasted requests | None | None | Many empty checks |
| Best for | React to events | Fetch on request | When no webhook exists |
Polling is the clumsy option: you ask "anything new?" every minute, and almost every time the answer is no. It wastes requests and still lags behind reality. A webhook flips that around. Nothing is sent until there is genuinely news, and when there is, it arrives at once. That is why event-driven systems, from payment processors to customer messaging, lean on webhooks rather than making you keep asking.
How a webhook works, step by step
Under the hood the whole thing is four moves. Once you see them in order, webhooks stop feeling like magic.
You register a URL
In the sending app's settings, you paste the address of your endpoint and pick which events you care about, say "new payment" or "new message." This is a one-time setup. From now on, the app knows exactly where to reach you.
An event happens
A customer pays, a form is submitted, an order ships. The moment that event occurs, the sending app notices and gets ready to tell you, without you having to check for it or refresh anything.
A payload is sent to your URL
The app makes an HTTP POST request to your endpoint, carrying a small packet of data called the payload. It describes what happened: the amount paid, the customer's details, the order number. Most payloads are formatted as JSON, which is easy to read and parse.
Your code reacts
Your endpoint receives the payload and runs whatever you told it to: send a receipt, update a spreadsheet, message a customer, book a slot. Then it replies with a quick 200 OK so the sender knows the message landed. The whole loop takes a fraction of a second.
What webhooks are used for
Almost any "when this, then that" automation you have seen is built on webhooks. A few of the everyday ones:
- Payments. A checkout tool fires a webhook the instant a charge succeeds, so your system can send a receipt and unlock access without you watching the dashboard.
- Form and lead capture. A new form submission pushes the lead straight into your CRM or inbox in real time, instead of sitting unseen until someone logs in.
- Messaging. When a customer sends a WhatsApp or Instagram message, the platform delivers it to your endpoint by webhook so a reply can go out in seconds.
- Code and deployments. A push to your repository triggers a webhook that kicks off tests and ships the new version automatically.
That messaging example is where webhooks quietly power a lot of modern customer service. When a shopper messages your business at midnight, a webhook from the chat platform is what lets an automated assistant read it and respond immediately rather than the next morning. A managed AI employee like Intellure sits on exactly that flow: it listens for the incoming-message webhook, understands the question, and answers, follows up, or books an appointment, all without you wiring a single endpoint yourself.
How to receive and test a webhook
Receiving a webhook means running a small piece of code at a public URL that accepts a POST request. When a request arrives, you read the payload (usually JSON), do your thing, and return a 200 status so the sender does not retry. During development you cannot point a service at localhost, so a tunneling tool exposes your local machine at a temporary public address for testing.
Because payloads are JSON, the first thing most developers do with a new webhook is print it and read it. A quick way to make a raw, minified payload legible is to paste it into a JSON formatter so you can see the exact fields and structure before you write code against them. Once you know the shape of the data, handling it is straightforward.
Webhook security: verify before you trust
Your endpoint is a public URL, which means anyone who finds it can send it fake data. A webhook that acts on every request it receives is a liability, so verification is not optional. Three habits cover most of the risk.
| Practice | Why it matters |
|---|---|
| Verify the signature | Most providers sign each request with a secret. Recompute that signature on your side and reject anything that does not match. |
| Use HTTPS only | An encrypted endpoint keeps the payload private in transit and stops it being read or tampered with on the way to you. |
| Respond fast, process later | Return 200 quickly, then do heavy work in the background so slow tasks do not cause timeouts and needless retries. |
Getting this right, signatures, retries, idempotency so a repeated delivery does not double-charge someone, is the part that eats real engineering time. It is also the reason a lot of small businesses would rather not run their own webhook infrastructure at all. If the goal is simply "answer customers the second they message," a managed service like Intellure absorbs the entire plumbing layer and hands you the result: instant, reliable responses with none of the endpoint upkeep.
Frequently asked questions
What is a webhook in simple terms?+
What is the difference between a webhook and an API?+
Do I need to be a developer to use webhooks?+
Are webhooks secure?+
What happens if my server is down when a webhook fires?+
The bottom line
A webhook is just an app tapping you on the shoulder to say "something happened," the instant it does, so your business can react in real time instead of waiting or checking. That real-time reflex is what makes the difference between catching a customer while they are still interested and losing them to a slow reply. You can build and secure the endpoints yourself, or you can let a managed AI employee like Intellure ride those event streams for you and turn every new message into an answer, a follow-up, or a booking, around the clock.