Webhooks suit online store events that need prompt processing; scheduled synchronisation suits periodic checks, larger datasets and sources without reliable events. A robust e-commerce integration often uses both. Orders can start immediately through a webhook, while stock or a reconciliation process runs on a schedule.
Choosing “real time or batch” is therefore not a matter of belief. Decide per data flow based on business impact, volume, source capabilities and recoverability.
What a webhook does and does not do
A webhook reports that something happened, such as a WooCommerce order being created or updated. The receiving integration validates the message, determines its relevance and records it for processing. The webhook itself need not execute the entire order process.
According to the official WooCommerce webhook documentation changes to orders, products and customers, among others, can trigger a message. A platform offering an event type does not mean every event is relevant to your process; that selection remains a functional design decision.
That last point matters. If an online store must wait for AFAS, a carrier and a payment provider during the webhook request, receipt becomes fragile. One slow external service can cause a timeout and a repeated message. Have the endpoint respond quickly after safely accepting the message, and put subsequent steps in a durable queue.
Webhooks are well suited to
- new or paid orders that need to reach accounting or fulfilment quickly;
- status changes with immediate significance for customers or employees;
- delivery and return events from logistics systems;
- changes where only the affected object needs processing.
When a schedule is stronger
Scheduled synchronisation checks at fixed times which data is new or changed. This is useful for large or changing datasets, sources without a complete event model and processes where some delay is acceptable.
Stock updates might periodically retrieve changed AFAS items. A nightly or more frequent reconciliation can also check whether every online store order eventually has a corresponding accounting record. This finds gaps caused by a missed webhook, temporary configuration error or manual intervention.
Scheduled synchronisation is well suited to
- catalogue and stock data efficiently read in batches;
- periodic checks between source and destination;
- historical recovery or an initial full synchronisation;
- processes without a reliable webhook mechanism.
Compare the two mechanisms
| Question | Webhook | Schedule |
|---|---|---|
| Speed | Processes shortly after the event | Depends on the interval |
| Load | Targeted per event | Efficient for batches, but may read large volumes |
| Missed change | Possible without a fallback | Can retrieve changes again |
| Peak behaviour | Queue must absorb peaks | Run can be paced |
| Recovery | Reprocess the event | Repeat by period or object |
Filter before creating work
Not every order update requires a full synchronisation. WooCommerce can produce several updates around one purchase. Filter for relevant order statuses and events, and combine short, related updates where needed. Retain enough information to process the final state correctly.
Also avoid an echo: system A changes system B, which sends an event back that makes A write again. Make recorded source identity, event identity and your own changes recognisable. Otherwise, an apparently small status change can start an endless or costly chain.
Design recovery from the outset
With either mechanism, failed processing must not be lost. Classify errors: a timeout can be retried, missing product mapping needs an employee, and an invalid message must be visibly rejected. Retain what was received, decided and executed at each step.
Make backlogs visible too. A queue that eventually processes every message can still fail operationally if orders wait for hours. Monitor not only error counts, but also the age of the oldest unprocessed message and time since the last successful source check.
A practical decision framework
- Describe how quickly the business outcome is needed.
- Check whether the source provides reliable, sufficiently detailed events.
- Determine whether the same event can be safely reprocessed.
- Design the queue and error handling before launch.
- Add a periodic completeness check for critical flows.
A concrete order process is described in connecting WooCommerce to AFAS. Read about the broader design of a recoverable chain in reliably integrating an online store and ERP. Yindle Connect combines events, scheduled processing, mapping and management in one integration layer.
Test scenarios for both routes
Do not test a webhook with only one manual message. Send the same event twice, deliver an older update after a newer one, make the receiver fail temporarily and check how WooCommerce handles failed delivery. The documentation notes that webhooks may be disabled after repeated delivery failures; monitoring therefore needs to detect such a stalled source actively.
For scheduled synchronisation, test an empty run, a large set of changes, a run that stops halfway and two overlapping runs. Check whether the next run continues without unnecessarily rewriting already confirmed results.
Frequently asked questions
Is synchronising every five minutes almost real time?
For some processes that is fast enough, but it remains an interval with potential load peaks and a maximum delay. Describe the business need instead of calling the mechanism “real time”. Also measure how long processing takes after retrieval.
Can webhooks replace periodic checks?
Not for critical completeness. Webhooks are a strong primary trigger, but configuration, delivery and processing can each fail. Separate reconciliation compares the business outcomes actually achieved and also finds errors that caused no technical alert.
When is a batch more useful?
When many similar records can be read together efficiently, immediate processing is unnecessary or the source only offers change selections. Pace the batch, retain progress and prevent one invalid record from blocking the entire set.
Unsure which parts need real-time processing and where scheduling is wiser? Map one value stream with Yindle, including events, checks and a recovery path.