On this page
Asking again and again, or being told
A webhook is about who starts the conversation. Without one, your software keeps asking another service whether anything changed: has that payment arrived, was that form filled in? That is polling. With a webhook the other service tells you itself, the moment it happens. You enter a web address once, for instance in your payment provider's dashboard, and from then on every message arrives there as a plain HTTP POST.
With a regular API integration you ask and the other side answers. With a webhook the other side speaks and you listen. In practice the two work together: the message says something happened, the API supplies the details.
Programmer Jeff Lindsay coined the name in May 2007. His comparison: on the Unix command line you have been able to chain programs with pipes since 1973, the output of one becoming the input of the next. The web had nothing like it; you had to keep checking yourself. "If you could avoid polling, you probably would", he wrote. Two years later GitHub showed how it works in practice, posting to an address of your choice on every code change. Today payment providers, accounting tools, CRMs and automation platforms all work this way. When a webhook alone is not enough, the four ways to connect two systems are on API integration services.
One hour of an online store: twelve requests or one message
One hour in an online store, between 14:00 and 15:00
Polling: ask every 5 minutes
12 requests, 11 times nothing new. The payment of 14:23 shows up at 14:25.
Webhook: the payment provider tells you
1 message, at the moment it happens.
How a Mollie webhook runs
- 01The customer paysBy card or Bancontact, at 14:23.
- 02Mollie sends a POSTTo your webhook URL, carrying only the payment id.
- 03Your server fetches the statusThrough the Mollie API, with your own key. Nobody can fake a payment that way.
- 04Reply 200 OKWithin 15 seconds. Otherwise Mollie retries, up to 10 times over about 26 hours.
Polling keeps asking whether something changed. A webhook turns that around: the other app tells you the moment it happens.
A 59 euro order, second by second
Say an online store sells bike locks and takes payments through Mollie, a European payment provider. At 14:23 a customer pays 59 euros by card.
- Within seconds Mollie posts to the store's webhook URL. The message holds only the payment id, not the status.
- The store fetches the status itself through the Mollie API, with its own key. Someone posting a fake message to the address cannot mark an order as paid that way.
- The store replies 200 OK within 15 seconds. If it does not, Mollie retries, up to 10 times, the last attempt about 26 hours later.
- The order is marked paid, the confirmation email goes out and the warehouse sees the order.
Without a webhook the store asks Mollie whether anything changed. Every five minutes, as in the figure, that is 288 requests a day, and the payment shows up as much as five minutes late. Every minute it is 1,440 a day and about 43,200 a month, for perhaps a few hundred payments. GitHub's own documentation puts it plainly: querying every resource separately quickly hits an API's rate limit.
Mollie and Stripe each do it differently
| Provider | What the message holds | How you know it is genuine | When your side fails |
|---|---|---|---|
| Mollie | Only the payment id | You fetch the status yourself through the API | 10 attempts, the last after about 26 hours |
| Stripe | The full event as JSON, e.g. that a payment succeeded | A signature in the Stripe-Signature header, HMAC with SHA-256 | Retries for up to three days, with growing pauses |
So read the provider's documentation before you build. Whatever the provider, polling and a webhook differ on five points:
| Question | Polling | Webhook |
|---|---|---|
| Who starts | Your software asks | The other service reports |
| Speed | As slow as your interval | Near instant |
| Load | Many empty requests | One message per event |
| When your server is down | You ask again later | The service retries, up to a limit |
| Choose it for | Services without webhooks, or a nightly export | Payments, forms, status changes |
The bill: per payment, not per message
Mollie charges 1.80% plus 0.25 euros for a European consumer card and 0.32 euros for an iDEAL payment in the Netherlands; the webhook itself is free. On the 59 euro lock that is 1.31 euros by card. The work sits on your side: an address that receives the messages over https with a valid SSL certificate, checks them and processes them.
Choose an automation tool if the message only needs to land in another package, such as a row in a spreadsheet or a contact in your CRM. Which tool needs which plan is in Make, Zapier or n8n.
Choose an endpoint in your own software if the message has to do something there: create an order, prepare an invoice, update a case file. That is a small, well-defined job next to building a web application or a client portal.
When a SaaS tool offers no webhooks and no API, sometimes only RPA is left, a robot that clicks where a person clicked. And giving an AI assistant access to your systems increasingly runs through MCP.
An endpoint that misses nothing: what your developer checks
- The address runs on https only, with a valid certificate.
- Every message is verified: a signature recomputed, or the status fetched from the provider.
- The server answers 200 at once and does the work in a queue afterwards, so a slow step causes no timeout.
- Duplicate messages do no harm: each event id is stored and nothing is booked twice.
- Order does not matter: a payment that arrives before its order still links up correctly.
- Every message is logged, so you can see later what came in and what failed.
- A nightly check through the API catches whatever an outage made you miss.
What developers and owners ask
What is a webhook URL?
The web address in your software where the other service sends its messages, for example https://yourstore.com/webhooks/mollie. You enter it with the provider. Treat it like a door: https only, and verify every message that comes in.
What happens when my server is offline?
Most providers retry. Mollie does so up to 10 times over about 26 hours, Stripe for up to three days. If your server stays down longer you lose messages; a nightly check through the API catches them.
Can someone send a fake message?
Anyone who knows the address can post to it. That is why you verify the signature when the provider sends one, or fetch the status yourself as Mollie asks. Never trust the content of the message blindly.
Do I need a developer?
Not if the message only has to become a spreadsheet row or a CRM contact: an automation tool does that. If it has to book something in your own software, yes.