Two systems that are meant to work together need a way for one to learn from the other: the order has come in, the invoice has been paid, the shipment has left. There are two basic approaches. With polling, your own system asks at fixed intervals whether anything new has happened. With event-driven notification, the other side gets in touch by itself the moment something occurs — that callback is the webhook. The difference sounds technical, yet it shows up directly in daily operation: in how long information takes to arrive, in the load on both systems, and in what happens when one side is temporarily unreachable. Quotations for interfaces usually state that data will be transferred, rarely how. This article explains both approaches without jargon, sets out what a webhook receiver has to provide, describes what happens during a fault, and names the cases in which quiet, regular polling remains the more robust choice. It ends with a decision aid — and with the insight that in practice the answer is rarely either or.
Key takeaways
- Polling is simple to build and forgiving of outages, but it creates waiting time and idle traffic: at a fifteen minute schedule that means 96 polls per day and interface, most of which find nothing new (worked example).
- A webhook reverses the direction: the other system calls an address you registered as soon as an event occurs. That cuts the delay to seconds and saves calls, but it requires a permanently reachable address on the internet.
- A dependable receiver accepts the message, acknowledges it immediately and only processes it afterwards. Putting the actual processing inside the acceptance step invites timeouts and the retries they trigger for the very same message.
- If the receiver fails, everything depends on the sender's retry logic. A retry window of at least 24 hours (project experience), an event log and a way to request missed messages therefore belong in the plan.
- In practice the combination works best: the webhook delivers speed, a daily reconciliation run closes gaps. Plain polling remains right when the other side offers no events or when the receiver must not be publicly reachable.
Two approaches, one goal: information at the right time
With polling, a schedule runs inside your own system. At fixed intervals it asks the other side the same question: since my last visit, are there new orders, changed stock levels, paid invoices? The answer is a list that is often empty. The approach is old, unglamorous and widespread for a good reason: on your side it needs nothing more than a schedule and an outbound connection to the internet. It therefore works even where your system sits deep inside the company network and nobody may reach it from outside.
With event-driven notification the direction is reversed. Your system registers an address with the other side once, together with a list of the events it cares about. When one of those events occurs, the other side calls that address and hands over the message. That callback is the webhook. Between two events nothing happens at all: no calls, no load, no empty responses. Information travels the moment it comes into existence, not in the next available time slot.
The difference is easiest to picture at a letterbox. Whoever polls walks downstairs every few minutes to look, usually in vain. Whoever has set up a notification stays at the desk until the bell rings. The second approach is obviously more economical — as long as somebody is at home when the bell rings. That condition decides whether a webhook brings calm to your business or trouble.
Both terms in one sentence each
What polling really costs in daily operation
The first price is waiting time. Between the moment a case comes into being and the moment it becomes visible in your own system lies, on average, half the polling interval, and in the worst case the whole interval. At a fifteen minute schedule that means an order arriving at 09:47 shows up at 10:00. For accounting that is irrelevant. For a picking team that puts together the day's tour at ten o'clock, it is the difference between today and tomorrow.
The second price is idle work. Every poll costs processing time on both sides, plus a schedule on your side that needs supervision. The worked example below shows the order of magnitude for a single connection; with several data types — orders, stock, payments, shipment status — the figure multiplies accordingly.
The third price stays invisible until it bites: many providers limit the number of calls per time window. Shortening the interval to become faster eventually hits that limit, and then you receive error messages instead of data. A tighter schedule does not solve the problem, it only moves it. A polling interval cannot be shrunk indefinitely — at some point the other side's limit is reached, not your own.
How an event-driven notification runs
Technically a webhook is unremarkable: the other side sends an ordinary request to an address you gave it and attaches the event data. Your system replies with a short confirmation. That is the whole transfer. Things only get interesting at the edges — at registration, at the acknowledgement, and in the question of what becomes of a message once it has been accepted.
The most common design mistake happens in step four. Many receivers process the message straight away, post the order, write into the merchandise management system, perhaps send a confirmation email — and only then reply to the sender. If that takes too long, the sender gives up and repeats the call. The case is processed a second time although it was posted long ago. Acceptance and processing therefore have to be separated.
Registration
You register an address with the other side and select which events you want to hear about. A shared secret is usually agreed at the same time, so that later messages can prove they are genuine.
Event
Something worth reporting happens in the other system: an order is created, a status changes, a payment arrives. The system turns this into a message with its own identifier, a timestamp and a reference to the record concerned.
Delivery
The other side calls your address and hands over the message, together with a signature in the header section. It waits only a few seconds for a reply — your system must not need longer than that limit.
Acknowledgement
Your system checks the signature, stores the message unchanged in a queue of its own and confirms receipt immediately. That confirmation says one thing only: arrived and stored. It says nothing about later processing.
Processing
Only afterwards does a separate job work through the queue: fetch the record from the other side, check it, post it, log it. Failures at this stage are your problem and are handled internally, not by returning an error to the sender.
You register an address with the other side and select which events you want to hear about. A shared secret is usually agreed at the same time, so that later messages can prove they are genuine.
Something worth reporting happens in the other system: an order is created, a status changes, a payment arrives. The system turns this into a message with its own identifier, a timestamp and a reference to the record concerned.
The other side calls your address and hands over the message, together with a signature in the header section. It waits only a few seconds for a reply — your system must not need longer than that limit.
Your system checks the signature, stores the message unchanged in a queue of its own and confirms receipt immediately. That confirmation says one thing only: arrived and stored. It says nothing about later processing.
Only afterwards does a separate job work through the queue: fetch the record from the other side, check it, post it, log it. Failures at this stage are your problem and are handled internally, not by returning an error to the sender.
What the receiver has to provide
Polling asks almost nothing of your side. A webhook does: the address has to be reachable from the internet, encrypted, permanently available and protected against outside access. That turns an interface into a small service that needs running — with monitoring, a log and somebody who notices when it stops. Skip that part and you have merely moved the problem from waiting time to availability. In companies without an IT team of their own, this task belongs explicitly in the agreement covering day-to-day IT operation.
The four building blocks below form the minimum. If one of them is missing the connection still works in normal conditions — the gap only shows on the day something goes wrong, and usually it shows silently.
Reachable address
A fixed, encrypted address that answers around the clock. Maintenance windows, restarts and certificate renewals have to be planned for, because every minute of unavailability pushes messages into the retry queue.
Immediate acknowledgement
Acceptance confirms receipt only and needs fractions of a second for that. Everything that takes longer — posting, validation, notification — belongs behind the queue, not in front of it.
Verified origin
A publicly reachable address can be called by anyone. Without checking signature and timestamp your system also accepts messages that nobody at the other side ever sent.
A queue of your own
Incoming messages are first stored unchanged, with identifier, timestamp and processing status. Later on this store is the only way to trace a failed processing run or to repeat it.
When the other side is temporarily unreachable
This is the question quotations leave out most often. At first the sequence is harmless: the sender calls your address, receives no answer or an error, and tries again later. Reputable providers retry with growing intervals so that an overloaded system does not come under additional pressure. An outage of a few minutes — a restart, an update, a brief network glitch — therefore passes without consequence.
Longer faults are the critical case. Every sender gives up eventually. Some systems even switch an address off permanently after a series of failed attempts, so that they do not keep sending into the void. From that moment messages are missing without anyone seeing an error: nothing arrives any more, and an empty inbox looks exactly like a quiet day. The most dangerous state of an event-driven interface is not the error, it is the silence.
Three things therefore belong in the plan. First, an event log at the other side from which missed messages can be requested afterwards. Second, monitoring that raises an alarm when no message has arrived for an unusually long period. Third, a regular reconciliation run that compares both data sets and names the differences. A retry window of at least 24 hours (project experience) on the sender's side buys the time a company needs to notice a fault at all.
- An immediate second attempt if the first reply fails to arrive or reports a technical error
- A further attempt after roughly a minute, to absorb short restarts and network glitches
- Then after a quarter of an hour, then after an hour, each time with a growing gap
- Further attempts at longer intervals until the agreed retry window runs out
- Once the window has passed: an entry in the log, an alert to monitoring, a request for the data through reconciliation
Security: who is allowed to knock?
A webhook address is publicly reachable. Anyone who knows or guesses it can send data to it. Without verification that means outsiders could create orders, set payment states or change stock levels. The usual protection is a shared secret agreed at registration. The sender uses it to build a checksum over the transmitted data and attaches it as a signature. Your system builds the same checksum and compares. If they differ, the message is discarded. The BSI, the German federal authority for information security, explicitly recommends protecting confidentiality, authenticity and integrity for such transfers (BSI).
A timestamp is added to that: messages older than a few minutes are rejected, so that a recorded call cannot be replayed later. Where the provider names fixed sender addresses, you can additionally restrict where calls are accepted from. And finally there is a rule that saves most of the trouble: the delivered payload is a hint, not the source of truth.
POST /webhook/orders HTTP/1.1
Host: receiver.example.com
Content-Type: application/json
X-Event-Id: evt-2026-06-01-000417
X-Timestamp: 2026-06-01T09:47:12Z
X-Signature: sha256=6f1c...
{"event": "order.created", "order": "A-2026-0417"}
# Reply from the receiver, immediately and without processing:
# HTTP/1.1 200 OK -> accepted and storedCheck the payload, do not believe it
Duplicate, late and reordered messages
Event-driven systems normally assure only that a message arrives at least once — not that it arrives exactly once. If an acknowledgement is lost on the way back, the sender considers the delivery failed and repeats it. Your system sees the same case twice. Without a safeguard this produces duplicate orders, duplicate postings or duplicate notifications to customers. The remedy is simple: every message carries a unique identifier, and processing remembers which identifiers are already done. A known identifier is acknowledged and discarded.
The order of arrival is equally uncertain. With retries and parallel deliveries, the message about a status change can arrive before the message about the record being created. Deriving state from the sequence of messages produces wrong results in rare cases — and those cases turn up precisely when things are hectic. It is more robust to fetch the current state of the record and to use the message timestamp only to recognise outdated information.
A message is a hint, not a posting record
When polling remains the more robust choice
Several situations make the older approach the more sensible decision. First, when the other side simply offers no events — with older systems and with connections through file drops that is the norm. Second, when your own system must not or should not be publicly reachable, for example because the merchandise management system sits on the premises and nobody wants an inbound connection through the firewall. Third, for bulk data: for a nightly full comparison of product master data, one file containing all records makes more sense than thousands of individual messages. Bringing data together from several sources also tends to run more cleanly in a scheduled job than in an event stream.
Fourth, and this is often overlooked: polling heals itself. After an outage the next run simply picks up every change since the last successful timestamp — provided the system remembers that timestamp. With a webhook the other side has to resend, and whether it does is not your decision. For cases where a few minutes of delay make no difference anyway, a webhook buys complexity without noticeable benefit.
| Criterion | Polling on a schedule | Event-driven notification |
|---|---|---|
| Delay | Half to a full interval | Seconds after the event |
| Setup effort | Low, outbound connection only | Higher, reachable address required |
| Load in normal operation | Constant, even without changes | Only when cases actually occur |
| Behaviour after an outage | Next run picks everything up | Depends on the sender's retries |
| Security | Credentials for the other side | Signature and timestamp on top |
| Suitability for bulk data | Good, one run for many records | Poor, very many individual calls |
| Operating effort | Supervise a schedule | Run a service, a queue and a log |
Running both: events for speed, reconciliation for safety
In most mid-size connections the answer is not either or but both. The webhook provides the speed: a new order is in the system within seconds and dispatch preparation sees it without waiting. A reconciliation run provides the reliability: once a night, or hourly for critical data, a scheduled job compares both data sets for a limited period and adds whatever is missing. That run is at the same time the control that makes a silent fault visible in the first place.
The extra effort for reconciliation is small, because it builds on the same access a pure polling solution would have used anyway. The gain is considerable: the interface loses its one dangerous property, which is falling silent unnoticed. For process automation projects it is worth planning that reconciliation from the start instead of retrofitting it after the first incident.
- Webhooks for time-critical individual cases: new orders, incoming payments, status changes in dispatch
- Scheduled reconciliation for stock and master data, where completeness matters more than seconds
- A nightly control run covering the last few days that lists differences between both systems
- Monitoring with a threshold: if no message arrives within a defined period, an alert is raised
- One shared log for both routes, so that a fault does not require searching two separate sources
Rolling it out: small steps
The change rarely succeeds as one large switchover. What works is starting with exactly one case where waiting time genuinely hurts today — usually the path from incoming order to order processing. For that single case the event notification is set up while the existing polling job keeps running. Both routes write to the same log, and after two or three weeks you can compare in black and white whether the messages arrive completely and how large the time saving really is.
Only once that parallel run is clean is the polling job reduced from a minute-by-minute schedule to a daily control run. Then the next case follows. This approach costs a few extra weeks but avoids the most unpleasant variant: a switchover after which nobody can say whether a missing order is down to the new mechanism or was never created at all. Which connection is worth the effort, and in which order, usually becomes clear from a sober assessment of the workflows involved before the first line of code.
Three questions for the provider on the other side
Sources
Related Articles
When an interface fails: spotting silent outages
Detecting, reporting and bridging silent interface failures: heartbeat, time windows, volume reconciliation, queueing and a defined restart procedure at work.
Automating file imports: six failure modes and their fixes
Daily file transfers between two systems: six typical failure modes from delimiters to duplicate deliveries, and how to check, log and report every one of them.
Invoice checks automated: order, goods receipt, invoice
Matching order, goods receipt and invoice by machine: which fields are compared, where the tolerance band sits, who owns the exception and what stays manual.