All articles

October 27, 2026 · 2 min read

What is a webhook? When the service tells you first

A webhook is an automatic call a service sends to your application when something happens. The idea, its pitfalls, and the good habits to apply.

  • tech
  • reliability

A webhook is a message a service sends automatically to your application as soon as an event happens, for example a successful payment. The service tells you, instead of you going to ask it.

The analogy: the doorbell

You are waiting for a parcel. First method: go down and check the mailbox every five minutes. Second method: the courier rings the bell on arrival.

The first is called polling: you keep asking, and most of the time the answer is "nothing new". The second is the webhook: the service calls an address you gave it, at the right moment.

How it works

  1. You give the service the address (a URL) of your application.
  2. An event happens on its side: payment confirmed, form received, message delivered...
  3. It sends a request to your address with the event's details.
  4. Your application answers "received", then does the work.

It is how an API works, but the other way round: here the service calls you.

Pitfalls to know

  • Duplicates. If your answer is slow or fails, the service retries, and the same event can arrive twice. Your code must be able to process it twice without a double effect: that is idempotence.
  • Disorder. Messages do not always arrive in the order the events happened.
  • Forged messages. Your address is public: anyone can send it a message claiming to come from the service.
  • Slowness. If your application takes too long to answer, the service may consider the delivery failed.

Good habits

  • Verify the signature. The service usually signs each message with a shared secret. Check it before trusting the content, and keep that secret out of code sent to the browser.
  • Answer fast, then process in the background with a queue.
  • Keep a trace of received events and how they were handled.
  • Handle duplicates by remembering each event's identifier.

A concrete example

Take an online shop (an illustrative example). When a customer pays, the payment service sends a webhook to the shop to confirm. The shop then marks the order as paid and prepares the shipment. Without it, the shop would have to keep asking the service "is this order paid?", or worse, rely on the page the customer sees on screen, which they may close before it finishes.

Key takeaway

A webhook is a doorbell rather than constant checking. You must verify who is ringing, and plan for it ringing twice.

And for your product?

Payments and notifications often rely on webhooks, and that is where costly mistakes hide: an order counted twice, a forged message accepted. A code audit of your application examines these points. We can talk about it in a 30-minute conversation.