What Is a Webhook?
A webhook is a reverse API call: instead of asking a system over and over whether something happened, the system itself calls you the moment an event occurs. A payment goes through, an order ships, a contract gets signed – and a message is sent immediately. Webhooks are efficient but can go missing and need acknowledgment.
Webhook is a word that sounds technical but rests on an everyday idea. If a regular API is about asking a system for something, a webhook is about the reverse: being told. It’s a small difference in direction with big consequences for how fast and efficiently systems can react to each other. Here’s the explanation, with an analogy that makes the principle obvious.
The doorbell versus the mailbox
Imagine you’re waiting for an important package. One way is to walk out to the mailbox every five minutes and check if it’s arrived. Most of the time you’re standing there for nothing, and yet the package could have been sitting there waiting for a while before you noticed it.
The other way is to have a doorbell. Then you don’t need to go out and check at all. The moment the package is delivered, it rings, and you react immediately. No waiting for nothing, no delay.
A webhook is the doorbell. Instead of your system asking another one over and over “has anything happened?”, the other system sends a small message on its own the moment something actually occurs. That’s why a webhook is often called a reverse API call: usually you’re the one calling, but here it’s the system calling you.
What it means in practice
The difference from asking constantly isn’t just elegance, it’s efficiency. Regularly asking a system means masses of calls where the answer ends up being “nothing new” anyway, plus a delay until the next question can be asked. A webhook sends word only when there’s something to report, and does it immediately.
The result is both fresher information and less load on both systems. You find out things the moment they happen, without wasting calls asking unnecessarily. For flows that need to feel instant, it’s often the difference between something that responds immediately and something that’s always a few minutes behind.
Business examples
Webhooks are invisible but drive event flows you encounter daily. A few typical ones:
- Payment completed. When a customer pays, the payment service sends you a webhook the moment the money goes through. You can then confirm the order immediately, without repeatedly asking the payment service whether the payment has arrived.
- Order shipped. When an order is packed and shipped, the warehouse or logistics system can send a webhook, so the customer gets their notification and the status updates automatically.
- Contract signed. When a document is signed in a contract service, a webhook is sent, and your system can move on to the next step – activating the service, creating the customer, starting the delivery – without anyone having to check manually.
Common to all three: an event in one system immediately triggers a reaction in another, without a human moving the information or a system sitting there asking.
An important note on delivery guarantees
There’s a catch worth knowing, though. A webhook can go missing. The message might be sent right when your receiver is down, get lost somewhere along the way, or accidentally get sent twice. Unlike when you ask yourself – and can ask again if the answer doesn’t come – you’re dependent on the sender reaching you at the right moment.
That’s why webhooks are built with two safeguards. The sender retries if the message doesn’t arrive, ideally with increasing intervals. And the receiver sends an acknowledgment, a confirmation that the message was received. If the sender gets no acknowledgment, it tries again until it gets through. Together they make sure no events silently fall through the cracks.
That doesn’t make webhooks unreliable – built right, they’re very robust – but it explains why a well-thought-out webhook integration is more than just receiving a call.
At Weapp we build integrations on webhooks and make sure they hold up in the real world, with retries and acknowledgments in place. Check out our services or get in touch.
Frequently asked questions
What's the difference between a webhook and a regular API call?
The direction. With a regular API call, you're the one asking another system about something. With a webhook, it's the reverse: the other system contacts you on its own when something happens. That's exactly why a webhook is often called a reverse API call. You wait for word instead of asking, which saves a huge number of unnecessary calls.
Why is a webhook more efficient than asking constantly?
Because you avoid all the calls where the answer ends up being that nothing happened. Asking a system regularly means masses of unnecessary requests and still a delay until the next question. A webhook sends word only when something actually happens, immediately. You get fresher information and put less load on both systems. It's more efficient both ways.
Can a webhook fail to arrive?
Yes, and that's its weak point. A webhook call can be sent while your receiver is down, get lost along the way, or accidentally arrive twice. Unlike when you ask yourself, you're dependent on the sender reaching you at the right moment. That's why webhooks need to be built with retries and an acknowledgment that confirms the message was received.
What's an acknowledgment in this context?
A response from you that confirms you received the webhook. When the sender gets the acknowledgment, it knows it doesn't need to send again. If it's missing, the sender tries again. The acknowledgment is what keeps events from silently disappearing: either they're confirmed, or they're resent until they get through. Without it, no one knows whether the call succeeded.
Where are webhooks used in practice?
Everywhere a system needs to know instantly that something happened in another one. Payment services send a webhook when a payment goes through, e-commerce systems when an order ships, contract services when a document is signed. Your integration then reacts the moment it happens instead of discovering the event late. It's the backbone of flows that need to feel instant.