Webhook

Programs on the internet need to notify each other. A payment service must tell the online shop that a payment has arrived. There are two ways to do this. Either the shop asks every few seconds: “Has the money arrived yet?” Or the payment service reaches out on its own as soon as there’s something to report. The second approach is called a webhook. For this, the shop registers a web address once, and the payment service sends a short message straight to that address when the event occurs.

Why asking every second gets expensive

Constantly asking has a name: polling. It wastes computing time and data traffic, since most requests just get the answer “nothing new.” Anyone processing a million orders a month while polling every second generates millions of pointless requests. With a webhook, exactly one message is generated per event. So the difference isn’t just technical — it’s also a matter of cost.

Then there’s the delay. Anyone polling every 60 seconds learns about news half a minute late on average. A webhook, on the other hand, usually arrives within milliseconds. For a purchase confirmation, that’s a nice bonus. For a server monitoring alert or a stock market price swing, it can be decisive.

For companies, webhooks are also the glue between pieces of software that otherwise have nothing to do with each other. A payment provider, an accounting program, and a shipping service come from three different vendors. Through webhooks, they still work together without anyone having to rewrite the programs.

What actually happens when it’s triggered

First, the recipient sets up an address that messages should be sent to. It looks like a normal web address, something like shop.com/hooks/payment. They enter this address in the sender’s settings and choose which events they want to be informed about. After that, they simply wait.

When the event occurs, the sender sends a small data packet to that address. It usually contains structured text listing the event type, timestamp, and details such as the amount or order number. The recipient replies with a success message. If that confirmation doesn’t arrive — because the server is overloaded or offline — the sender tries again later, often with increasing wait times between attempts.

Two points are tricky. First, the recipient must verify that the message really comes from the correct sender, since the address is publicly reachable. To do this, the sender attaches a cryptographic signature — a checksum computed using a secret key. Second, the same message can arrive multiple times due to retries. The recipient must detect duplicates, otherwise the shop might ship the same item twice.

Webhooks in AI services and everyday software

In chat and team tools like Slack, Discord, or Microsoft Teams, webhooks are behind almost every automatic notification. When the developer channel shows that new code has just been uploaded, a webhook from GitHub triggered that message. Automation services like Zapier or IFTTT are built on this too.

Webhooks are especially important for AI applications that take a long time to compute. A video generator might need three minutes to produce a clip. The calling app doesn’t sit idle waiting — instead, it registers a webhook address and moves on. Once the video is ready, the notification arrives with the download link. Providers like OpenAI or Replicate offer exactly this kind of callback for that purpose.

Webhooks shouldn’t be confused with a regular programming interface, or API for short. With an API, you actively request something and wait for the response. With a webhook, the direction is reversed: the service calls back on its own. That’s why the method is also called a callback. In product descriptions, you’ll often find “webhook support” mentioned as a selling point, because it shows that a tool can be integrated into existing workflows.