A webhook is a notification a system sends of its own accord to a previously registered address when a particular event occurs. It reverses the usual direction: rather than the interested system asking, the originating system reports in.
How it differs from polling
The alternative is asking at regular intervals whether anything new has happened. That is simple to implement and inefficient in two ways: most requests return nothing new, and a delay arises between two requests. Webhooks remove both — in exchange they shift complexity to the receiving side, which must now be reachable at any time and cope with unreliable delivery.
Repeat delivery is the norm
The most important practical property: a webhook can arrive more than once. That happens when the receiver’s response is lost, when a timeout occurs, or when the sender retries as a precaution. A receiver assuming it sees each event exactly once produces duplicate invoices, duplicate emails or duplicate bookings. Processing must therefore be idempotent — processing the same message twice must leave the same state as processing it once.
Order is not guaranteed
Nor can you rely on events arriving in the order they occurred. A status change can arrive before the creation. Robust receivers therefore check the event’s timestamp or version number and discard anything older than the state already processed.
Verifying authenticity
A webhook address is publicly reachable so that the sender can reach it. That means anyone can in principle send messages to it. Reputable providers therefore sign every delivery with a shared secret, and the receiver verifies that signature before processing. Omitting that check means allowing anyone on the internet to trigger state changes in your system.
Answer fast, work slowly
A receiver should acknowledge delivery immediately and do the actual work afterwards. Completing processing before responding runs into timeouts, which cause retries, which raise load — a feedback loop that escalates under pressure. The usual solution is to accept the event, store it, acknowledge, and process asynchronously.
Practical consequence
A robust webhook receiver needs four things: signature verification, idempotent processing, insensitivity to ordering, and a fast acknowledgement with deferred work. Missing any one of them, the integration works in a demonstration and breaks in operation.