Batch sync or read live from the ERP: which one should your B2B storefront do?

A batch sync copies. On a schedule, something reads a set of records out of Acumatica or Cin7 and writes them into Shopify, BigCommerce, Shopware or Drupal Commerce, where they sit as ordinary platform data. The storefront then serves them without knowing the ERP exists. A read-through does not copy. When the page needs a number, the storefront asks the ERP for it, usually through middlewareMiddleware is a layer of software that sits between the ERP and the storefront, translating and enforcing rules that neither system holds on its own. It can be a hosted integration platform or a custom service., and renders whatever comes back.

The trade is the same one every caching system makes. A batch sync gives you speed, independence from ERP uptime and cheap scaling, and it pays for that with data that is always at least one cycle old. A read-through gives you accuracy at the instant of reading, and it pays with latency, with load on the ERP, and with a hard dependency: if the ERP is not answering, the page has nothing to show.

The mistake almost every project makes is treating this as one decision for the whole integration. It is not. A product description that changes twice a year and a stock figure that changes forty times an hour have nothing in common except that they both live in the ERP. The useful version of this decision is a table with one row per field.

Eventually consistent is a phrase engineers use to mean the two systems will agree in a while, and nobody promises how long a while is. Translated for a buyer, it means the number on the screen is a report about the past. It was true when the sync ran. Whether it is true now depends on what your warehouse and your counter staff have done since.

Put a real cadence on it and the problem becomes concrete. If stock syncs on a four-hour cycle, which is what SparkLayer documents for Cin7 Core, then in the worst case a buyer is reading a number that is three hours and fifty-nine minutes old. For an item that sells twice a week that is irrelevant. For an item where a single counter sale clears the shelf, you have shown available stock on something that went out of the door before lunch, and the customer finds out when their order is short-shipped.

The honest arithmetic is a division, and you can do it per item without any tooling. Take the item’s average units sold per hour across your busiest hours, multiply by the sync interval in hours, and compare the result to the quantity you typically hold. If the sync window can consume a meaningful share of your holding, batching that item is a decision to oversell it occasionally. That is a legitimate decision if you make it deliberately and staff the exception process, and it is a bad surprise if you find out from a customer.

The Acumatica and Cin7 communities both carry the operational version of this. Acumatica has an open thread about UNASSIGNED commitments causing the Shopify connector to publish the wrong available quantity, and Cin7 Core’s documented behaviour is that manufacturing availability is drawn from finished-goods stock and ignores raw material and component availability. In both cases the number is calculated from the wrong base rather than simply being out of date, and no increase in sync frequency will fix that.

Work through your integration one field at a time and put each into one of three buckets: batch it, read it live, or do both by batching a display value and reading live at the decision point. The third bucket is where most good B2B integrations end up, and it is worth naming because platform vendors rarely describe it.

The pattern behind bucket three is simple. Show a batched number on the listing page, where the buyer is browsing and a stale figure costs nothing, and read live at the moment the buyer commits, which is the cart or the checkout. That gives you a fast catalogue and an accurate order, and it puts the ERP call on the one page per session where a hundred milliseconds does not matter.

Note that some of these decisions are made for you by the platform. BigCommerce has no concept of inventory locations, which Acumatica’s own community moderator has stated, so per-warehouse availability there needs a customization keyed on something like the ship-to state regardless of whether you batch or read live. Cin7 Core does not auto-push product edits at all: its Shopify FAQ documents a manual Load Products then Publish Product step, which makes product content a batch decision with a human in it.

This is the constraint that turns an elegant read-through design into an outage, and it is almost never modelled before build. A batch sync has a cost you can calculate in advance: records divided by page size, multiplied by runs per day. A read-through has a cost that scales with traffic, and traffic includes crawlers, which do not buy anything and do not stop.

Do the estimate before you design. Take your monthly product page views, add your listing page views multiplied by the number of products on a listing page if you have not built a batch endpoint, and add whatever your search engine crawler does to a catalogue of your size. That is your read-through call volume before any caching. Then apply your cache hit rate honestly, remembering that a per-customer cache key means the hit rate on a long-tail catalogue with many accounts is far lower than the number an engineer will guess.

On the ERP side, both vendors meter. Cin7 documents API call limit errors as an ordinary integration FAQ item, which tells you they are common enough to write a help article about. Acumatica meters API access by licence, and the shape of the limit depends on the licence tier you hold, so the number that applies to you is in your own contract rather than in a blog post. We are not going to publish a figure for either, because the figure that matters is the one your instance enforces, and it is worth ten minutes with your VAR to get it in writing before you design around it.

The practical protections are the same in every design: cache aggressively at the edge, put a batch endpoint in front of anything that renders a list, rate-limit your own integration below the ERP’s ceiling so you fail politely rather than getting throttled, and keep a queue in front of writes so a throttled call retries instead of dropping an order.

More often than an integration specialist will tell you. A nightly batch is cheap to build, easy to monitor, trivially restartable, and it keeps trading when the ERP does not. If your catalogue and your commercial model allow it, choosing it is good engineering rather than a compromise.

The situations below are the ones where we would argue against paying for anything cleverer in phase one. If your business is in three or more of them, buy the batch, spend the difference on product data, and revisit in a year with real traffic to look at.

And the converse, stated plainly so this does not read as a sales page for the cheap option: if you sell fast-moving stock from multiple warehouses to accounts with enforced credit limits, a nightly batch will oversell, misprice or accept orders you cannot fill, and the cost of that lands on your order desk rather than on your IT budget, which is why it stays invisible until someone measures it.