You can safely handle a webhook storm by briefly grouping rapid notifications about the same order, then retrieving the latest order data while keeping every received notification in the audit trail. A queue alone is not enough: without grouping, one checkout can trigger five almost identical synchronisations, causing unnecessary API load, outdated updates and duplicate follow-up actions.
Why one order produces several notifications
WooCommerce may report an order's creation, payment status, stock movement and order update in succession. Payment, fulfilment or custom-field plugins can add more updates. This is normal behaviour; it becomes a problem when every message independently triggers the entire chain to the ERP, carrier and customer service team.
A robust integration layer therefore separates receipt from processing. Receipt must be fast, durable and traceable. Processing can wait a few seconds to see whether a newer notification for the same order number follows. The grouping process then selects one candidate, while keeping the other events in the history. This makes it possible to see later why processing started at that moment.
The burst decision tree
- Is it the same store and the same order object? Only then can notifications be grouped. Matching order numbers from different online stores represent different orders.
- Does the notification fall within the short grouping window? Wait long enough to catch a checkout burst, without noticeably delaying fulfilment.
- Has earlier processing already started? Flag the new event for a follow-up check instead of letting two processes write to the same order at once.
- Which version is the latest? Do not blindly use the last message received; retrieve the current order where possible and compare modification times.
- Which follow-up steps have already succeeded? Never repeat a shipping label or payment simply because the source sent another notification.
This approach fits a reliable integration between an online store and ERP: events are signals to start controlled work, not automatically the truth that overwrites every system.
Fictional example: three updates in twelve seconds
Suppose online store Noord & Noot receives order 4812. At 10:03:01, WooCommerce reports that the order has been created. Four seconds later, the payment plugin confirms payment. At 10:03:12, a shipping plugin adds a delivery instruction. Without grouping, the system may attempt to create three AFAS sales orders and three parcel requests.
With grouping, all three notifications are recorded under the same store and order. After the window closes, Connect retrieves the current order again. It contains both the payment status and delivery instruction. One primary processing run creates the financial order. Only after that succeeds is the appropriate logistics step released. In Desk, the timeline still shows that three source notifications were combined into one processing round. This example is fictional; it illustrates the problem that this technical sequence solves.
What to measure during implementation
| Signal | Healthy outcome | Investigate discrepancies |
|---|---|---|
| Notifications per order | All notifications remain traceable | Missing webhook record |
| Processing runs per burst | Usually one primary run | Window too short or incorrect key |
| Latest change | Current source version processed | Clock, cache or late delivery |
| Follow-up actions | No duplicate labels or entries | Missing idempotency or receipt checks |
Look beyond speed. More important are the number of grouped events, the age of the selected source version and the number of actions that need manual attention after an uncertain error. In Yindle Connect such a flow can be configured as a workflow; in Yindle Desk a staff member can review exceptions and the audit trail.
Also test the grouping window with traffic that resembles your store's. Create a test sequence with a normal checkout, a payment confirmation arriving twenty seconds later, two identical updates and a correction while the first processing run is still in progress. Check not only how many jobs start, but also the order state that eventually reaches each target system. An aggressive window may neatly reduce the first processing run yet still miss a later, meaningful change. A targeted follow-up check must therefore take place after an active processing run. Set an acceptance criterion that the latest valid source change has demonstrably been processed and that non-repeatable side effects have occurred at most once.
Want to know where your online store is processing the same order unnecessarily often? Let us review a representative webhook sequence with you.