Webhook
- Standard term
A webhook is a web address you give another service so it messages your app when a chosen event happens, such as a completed payment, without your app checking over and over.
After sending each message, the service waits for your app to reply that it arrived. If the reply is slow or never comes, the service sends the message again. So one event can arrive twice, late, or out of order.
Where you’ll meet it
Your AI built a small app that takes payment for your online workshop and emails each buyer a welcome note. A buyer writes back asking why the welcome email came twice, and your app's list shows them as two separate signups.
What to do
- Ask your AI to make the app save each event's ID and skip repeats.
- Make a test payment, resend its event from the service's dashboard, and check for one email.
Easy to mix up
| Webhook | Polling |
|---|---|
| Messages sent while your app stayed down past the retries | Changes that came and went between two checks |
Check yourself
When a message saying "payment completed" arrives at your app's webhook address, the app's only step is to set that order's status to paid. Which is the risk?
Go deeperSignatures and retry timeouts set how the receiving app is built
Most services sign each message with an HMAC, a code computed from a secret key they give you and the message's exact bytes. The app checks it before reading the raw message into fields, since any reformatting changes the bytes and breaks the match. A timestamp inside the signed part lets the app refuse an old message replayed later.
Providers often wait only seconds for a reply before counting a delivery as failed. So the app records the event, answers, and leaves slow work such as emails to a queue, a waiting list of jobs. The code for each kind of event also checks the record's current state before acting, so a late "subscription updated" can't overwrite a newer change.