Real time or batch: how fast should the store and ERP sync?

The short answer

An integration does not have one speed. Each stream gets the speed that matches who is waiting for it. A buyer on a product page and a picker in the warehouse wait in seconds. An accountant who reconciles payouts waits until tomorrow morning.

There are four cadences, and most integrations use all four:

The choice per stream comes from two questions: how much harm a value an hour old does, and how many calls the source system allows.

What has to move within seconds

Stock on items that are nearly gone. Item 10482 shows 3 available in the store. At 10:02 a sales rep enters a phone order for 3 in the ERP. Stock syncs to the store every 30 minutes, at 10:00 and 10:30. The store sells 1 at 10:11 and 2 at 10:24, all against stock that no longer exists: 3 units oversold, 3 orders to cancel or backorder. An item that sells 4 an hour sells 2 on average in a 30-minute interval, so the interval has to be short wherever the units left are close to that number. Shopify sends inventory_levels/update when a level changes; in the other direction the ERP pushes the new figure or the integration polls it.

A payment that releases an order. The warehouse picks once the payment is captured. Say the carrier pickup needs orders released by 2:00 pm. An order paid at 1:40 pm under a 30-minute poll can reach the ERP at 2:10 pm and ship a day later. Shopify sends orders/paid for exactly this moment.

Cancellations and credit holds. A cancellation that takes 20 minutes arrives after the box is packed. A customer put on credit hold in the ERP should lose the option to order on terms in the store the minute the hold is set.

What waits for a scheduled run

Data that is used the next working day gains nothing from speed.

A scheduled run has three advantages. It can be checked: one run, one line count, one total, next to yesterday's. It loads the source system when nobody is working in it. And it leaves the daytime call budget to orders. One iPaaS implementation guide for a store and NetSuite recommends a 24-hour lag on its payout flow for the reason in the table.

What polling costs

Every poll costs calls, whether anything changed or not. Take a store with 72 orders a day and a poll that makes 5 calls per run: new orders, cancellations, refunds, stock and customers.

The sums: 1,440 runs times 5 calls is 7,200, divided by 72 orders is 100. In the last row the webhook carries the order itself, so the only API calls are the 96 single-call reconciliation runs.

Where those calls land decides whether they hurt. Business Central online allows 6,000 OData requests per 5-minute window per user, and 5 at the same time; every integration that signs in as that user shares the window. NetSuite counts concurrent requests per account: 5 on the Standard tier, 15 on Premium, 20 on Enterprise and Ultimate, plus 10 per SuiteCloud Plus license, shared by every integration on the account. A poll that runs every minute holds one of those slots 1,440 times a day, mostly to learn that nothing changed. The details are in NetSuite concurrency and governance limits and the arithmetic for full runs in integration throughput.

Event-driven is not instant, and lags add up

A webhook is fast but not immediate, and not complete. Business Central waits 30 seconds after the first change before it sends a notification, sends one collection notification when more than 1,000 records change in that window, and lets a subscription expire after 3 days unless it is renewed. salesShipments is not on its list of webhook-enabled APIs, so shipments from Business Central are polled. Shopify retries a failed webhook 8 times over 4 hours and then deletes the subscription. A webhook stream therefore always runs with a reconciliation poll next to it, as described in webhooks are not a guarantee.

Polled flows often add a deliberate lag: a run only reads records older than a set number of minutes. The same implementation guide recommends 10 to 15 minutes on the order flow, so an order reaches its final payment status first, and 5 minutes on fulfillments, so tracking numbers are on the record. Interval and lag add up:

A 15-minute interval with a 15-minute lag delivers an order 15 to 30 minutes after it was paid, 28 minutes for order 1047. A billing flow behind it with its own 60-minute lag puts the invoice over an hour after checkout. The lag solves a real problem, a payment or fraud check that changes the order right after it is created. Reacting to orders/paid instead of orders/create solves it without the wait.

Choosing an update schedule for each data flow

Real time is not a setting for the whole integration. It is decided per flow, by who is waiting for the answer.

Events have their own limits. Shopify expects a webhook to be answered within five seconds and retries a failed delivery up to 8 times over 4 hours, after which the subscription is removed. BigCommerce retries over a longer schedule and deactivates a webhook 48 hours after the first failed attempt. A webhook can also arrive twice. So an event is a trigger, and a scheduled read behind it catches what an event missed. The detail is in webhooks are not a guarantee and real time versus batch.

What this means for your integration

The cadence is a design choice per stream, not a property of the integration. We set per stream what starts a run, how old the data may be and how many calls that costs against the limits of your systems, then build, host and run it. Orders and stock go per event or in short polls, with a queue and a reconciliation run so a missed webhook is picked up. In the dashboard you see each run and what it changed.

How this works for stock is on stock and availability, and the order flow with its fields on orders, customers and shipping. Tell us which store and ERP you run, and you hear which streams can run per event and what the rest costs in calls.