What Is a Webhook? A Plain-English Explanation

The one-sentence version: they call you, you don't call them

An ordinary API call runs on your schedule: your app decides it needs something and asks for it. A webhook flips that around entirely. You give a service (PayFast, Yoco, WhatsApp) a URL belonging to your own app, and from that point on, the service calls that URL itself, whenever a specific event happens, without you asking first. You're not checking in to see if a payment went through; the payment platform tells you the instant it does.

This is also the practical reason a webhook exists at all rather than your app just asking repeatedly. Constantly polling "has this payment completed yet?" wastes requests, adds delay, and doesn't scale once you have real traffic. A webhook is push instead of pull: near-instant, and only as much traffic as events actually happening.

Why your AI builder needs a real backend to receive one

A service calling your webhook has to reach it over the open internet, the same way a visitor reaches your homepage. That means your webhook receiver has to be deployed somewhere with a real, public address before it can catch anything, not sitting on your own machine during a preview session. This is why an AI builder's in-browser preview usually can't receive a webhook on its own, and why the receiver lives in a backend function with a public address instead. Our guide to adding a payment gateway shows where that receiver fits in a real checkout.

The one thing every webhook receiver has to do: verify the signature

A webhook URL is a public address, which means it's also something anyone who finds it can call, not just the platform you set it up for. Every service that sends webhooks solves this the same way: it signs each request with a secret only the two of you know, and your receiver has to recompute that signature and check it matches before trusting anything in the payload. PayFast signs with MD5 over the field values, Yoco and WhatsApp both use HMAC-SHA256, Peach Payments signs the checkout request and the webhook independently, different exact mechanics per platform, same underlying rule every time: recompute, compare, only act on a match.

Skipping this step is the single most expensive mistake a webhook receiver can make, and it's an easy one to make by accident, since an unverified webhook that trusts every incoming request looks identical to a properly verified one in a quick test. The gap only shows up once someone deliberately sends a fabricated request, at which point a fraudulent order can get marked paid, or a forged message treated as a real customer contact. Build the signature check into the first version of every webhook receiver; never leave it as a follow-up step to add "once it's working."

What you'll actually see: event, payload, retries

A handful of words show up on almost every webhook, worth recognising rather than treating as new each time. The event is what actually happened, a completed payment, a received message, and most platforms send a specific event type so your receiver knows which one it's looking at. The payload is the data describing that event, sent along with the call. A retry is what happens if your receiver doesn't respond in time or errors out, most platforms attempt delivery again on a schedule, though exactly how many times and over what window differs by service.

Not every webhook behaves the same way

Two webhooks that look similar on the surface can still differ in ways worth checking before you assume either one. Some platforms send a test event automatically the moment you register a URL, purely to confirm it's reachable, separate from the real event webhooks that follow, which is why a receiver built to expect only one payload shape can fail on that very first call. Retry behaviour, how many attempts and how far apart, isn't standardised across platforms either. And a webhook's own payload format can change between a platform's API versions, which is why this site's own integration guides name the date they were last checked against the platform's current documentation, the same honesty this site's guide to APIs already covers in more depth.