Webhooks vs. Polling: Event-Driven Shop Integration

Polling is the older and simpler pattern. The target system calls an interface of the source system at a fixed cadence and asks: is there anything new since my last request? In a shop-to-ERP integration, the ERP might query the shop API every five minutes for new orders. The advantage is simplicity: the source system needs to know nothing about its consumers, and the client controls the cadence itself. The disadvantage is obvious: on average, half the interval elapses between an event and its processing, and most requests return no new data.

Webhooks reverse the direction. As soon as an event occurs in the source system, it sends an HTTPS POST on its own to a pre-registered URL on the target system. Latency drops to seconds and no load is generated by empty requests. In exchange, complexity shifts: the target system must operate a publicly reachable endpoint, verify the authenticity of every message and cope with the fact that a delivery can also fail. In practice this shift pays off, because it reflects the reality of event-driven business processes. A well-designed ERP integration chooses the pattern not ideologically but per data flow.

The economic relevance grows with the maturity of the integration. In our experience, an average of 31 percent of large organizations' IT budgets goes to integration and API work (project experience). Insufficient documentation and inconsistent interfaces prove to be recurring main obstacles to API adoption (project experience). The more systems talk to each other, the more important a consistent pattern for event transport becomes. Those who rely on clean contracts, signatures and retry logic from the start save considerable maintenance effort later in interface development.

The decisive difference between the two patterns lies in data currency and the system load they generate. For time-critical events such as incoming orders or stock changes near a threshold, every second counts. German B2B e-commerce, with a sales volume in the triple-digit billions, is among the fastest-growing distribution channels (BEVH, 2024), and short response times between shop and ERP are a technical foundation for it. For less volatile data such as product descriptions or a nightly master-data reconciliation, a delay of minutes is uncritical by contrast. The following overview summarizes the typical characteristics.

Polling has an often-overlooked advantage: predictability. Because the target system sets the cadence, load spikes are plannable and the source system is never overrun. This becomes a challenge with webhooks when a single event in the source system generates many follow-up messages, such as a price-list import touching tens of thousands of items. Server-side batching or throttling helps here. According to Gartner, integration initiatives fail above average precisely on such non-functional requirements as load behavior and fault tolerance (Gartner, 2024), not on the actual business logic.

In a distributed system there is no perfect delivery without trade-offs. Three models are common: at-most-once (delivered no more than once, loss possible), at-least-once (delivered at least once, duplicates possible) and exactly-once (delivered exactly once). True exactly-once across system boundaries is costly and rarely necessary in practice. The pragmatic standard for shop-to-ERP data flows is at-least-once combined with idempotency on the receiver side, so that duplicate deliveries cause no harm.

Concretely this means: the webhook receiver acknowledges a successfully accepted message with a 2xx status code. If it does not respond, or responds with an error, the source system repeats the delivery according to a wait pattern. This is exactly where duplicates arise, when the first delivery was processed but its acknowledgement was lost. The solution is a unique idempotency key per event, which the receiver stores and against which it checks every incoming message. An in-depth treatment of this topic is available in the sister article on idempotency and retry strategies.

Polling has a structural advantage in delivery: if the client misses a request, for example due to maintenance, the next run catches up on all interim changes, as long as the cursor is advanced correctly. Nothing is lost because the target system controls its own position. This property makes polling the ideal safety net behind webhooks and is the core of the hybrid approach described below.

A webhook endpoint is publicly reachable, so it must treat every message as potentially forged until its authenticity is proven. The most widespread method is an HMAC signature. The source and target systems share secret key material. The source system computes an HMAC over the raw message body, usually with SHA-256, and sends the result in an HTTP header. The receiver recomputes the HMAC with the same secret and compares the two values. If they do not match, the message is discarded.

Two details determine the quality of the check. First, the signature must be computed over the unaltered raw body, not over a re-serialized JSON, because even a reordered set of keys breaks the signature. Second, the comparison must run in constant time so that an attacker cannot draw conclusions from timing differences. According to the OWASP API Security Project, missing or flawed authentication and authorization are among the most frequently exploited weaknesses in interfaces (OWASP API Security Top 10, 2023).

Polling has a different, simpler security profile here. Because the target system establishes the connection, server-side credentials such as an OAuth token or an API key suffice, and there is no inbound endpoint to protect. This smaller attack surface is a real advantage that is often underrated when comparing the two patterns. A professional interface design weighs the currency gain of webhooks against the lower security effort of polling on a per-data-flow basis.

No receiver is permanently reachable. Maintenance windows, deployments, overloaded databases or network outages are the normal case, not the exception. Robust webhook processing answers the question of what happens to an event whose delivery fails. The proven answer is a retry with exponential backoff: after the first failed attempt the source system waits briefly, then increasingly longer, for example after a few seconds, then minutes, then hours, until a maximum is reached.

An important detail is jitter, a random spread of the wait times. Without jitter, all queued events would be redelivered simultaneously after an outage and could immediately overload the receiver that has only just recovered. Events that could not be delivered after all attempts move into a dead letter queue. There they rest safely for later manual or automatic reprocessing and trigger an alert. This very mechanism ensures that even a longer outage does not mean data loss.

On the receiver side, resilience also means separating heavy processing from acceptance. The webhook endpoint validates the signature, writes the message into an internal queue and responds immediately with 2xx. The actual processing, such as creating an order in the ERP, happens asynchronously through workers. If processing fails, it is retried from the internal queue without the source system being affected. This decoupling is a central principle of any resilient integration architecture.

In a real integration between shop and ERP there is not one data flow but a dozen, each with its own currency and load requirements. The art is to choose the right pattern per flow rather than treating everything the same. Orders, payment and shipping status are classic push candidates because here seconds count. Master data, price lists and a nightly consistency reconciliation are classic pull candidates because here completeness matters more than speed.

This mix is not a compromise but the superior solution. According to a survey by the industry association BITKOM, mid-market companies see the automation of business processes as one of the most important levers for efficiency gains (BITKOM, 2024). Statista reports sustained double-digit growth in German digital commerce over recent years (Statista, 2024), which further increases the pressure on resilient system integrations. A well-designed event transport is the technical prerequisite for this, because it determines whether the automation runs fast, reliably and traceably. Across more than 50 integration projects (project experience), the described hybrid approach has proven a robust standard.

The mature standard for shop-to-ERP data flows is neither pure polling nor pure webhooks, but a deliberate combination. Webhooks provide the low latency for time-critical events. A periodic delta polling runs as an independent safety net in the background and catches everything the push path lost or missed. The middleware between the systems implements both and decouples business processing from reception.

This layer performs several tasks simultaneously: it validates incoming webhook signatures, persists each event with its idempotency key, processes it asynchronously toward the ERP and runs the delta reconciliation in parallel. As a result, the system is resilient against individual failures without the shop or ERP noticing any of the complexity. Anyone wishing to modernize an existing integration can introduce this approach incrementally, for example by first switching the most critical flow to webhooks while the rest continues to run via polling for now. An accompanying integration consultation helps to align the sequence with your processes.