Which ERP can run a real-time B2B storefront?

It means a call to the ERP while a human is waiting. Everything else people call real time is a fast batch, and a fast batch has no rate limitA rate limit is the cap a system puts on how many API requests you may make in a period. Go past it and requests are rejected until the window resets. problem worth discussing. The distinction matters because the two designs fail in completely different ways and cost completely different amounts.

Three things on a B2B storefront genuinely want a live call. The price a specific buyer pays, when that price comes from a contract rather than a published list. The quantity available to promise from the warehouse that buyer ships from. And the buyer’s credit position, if you intend to stop an order rather than call about it afterwards. A public catalogue, product content and search do not need a live call and should never make one.

So the sizing question is narrow and answerable: how many ERP calls per second will your storefront make at peak, and what does your ERP publish as its ceiling. Three of the four ERPs below publish a number. One publishes only that limits exist. That single difference is most of what this page is for.

Every figure below is quoted from the vendor’s own document, read on 20 August 2026. Numbers move between releases, so take these as the shape of each vendor’s model and confirm your own edition, service tier and environment before you design against them.

Read the last row first if you are short of time. It is the one that changes an architecture decision rather than a capacity estimate.

Through two separate ceilings, both published by Acumatica, and both worth sizing before a project starts rather than after. This is sizing guidance. Nothing here is a defect, and every number comes from Acumatica’s own documents.

The first ceiling is transaction volume. Acumatica’s April 2026 Licensing Guide defines the Monthly Commercial Transaction Volume as "the single highest volume of transactions for any of the following eight (8) transaction types: sales orders (of any order type); shipments; AR invoices; customer payments; purchase orders; purchase receipts; AP bills; and AP payments", and states that "ERP transactions will also result from automated schedules that execute batch processes and/or REST APIs that create, update or delete transactions". The guide’s transaction tiers run from S1 at 1,000 a month to P2 at one million. Exceeding your tier "creates an out-of-compliance situation, which may require you to increase your Transaction Tier level mid-contract".

The second ceiling is request throughput. The same guide publishes Web API maximums of 50 requests a minute on Essentials, 100 on Select, 150 on Prime and 300 on Enterprise, with API concurrency queue sizes of five, ten, 20 and 40. Acumatica’s guidance when integrations need more is to submit "fewer requests when the system is busy", to add processing nodes, or to use SaaS Reserved Resources, all of which are real options with real costs.

An older Acumatica document says the same thing in a blunter way and is still published on acumatica.com. The Licensing Guide Supplement, dated May 2018 in its own header, states that "if using APIs, OData Export, or scheduled import/exports to run automated background processes, the maximum number of concurrent users and hourly transaction volumes will be lower than that shown in the above table", and that "once guidance levels are exceeded, users may begin to see significant performance degradation". Its resource levels ran from Small at 100 peak transactions an hour to 4X-Large at 4,000. That model has been superseded by the transaction tiers in the April 2026 guide, so use the current guide for numbers and the supplement for the principle.

The lived version appears in Acumatica’s own community. Thread 15799, "eCommerce and API Limits", from April 2023, has a poster describing a 100 calls per minute limit on their licence, calls "getting denied or throttled", and real-time pricing that needed several calls per item breaking under it. The answer, from a community MVP rather than Acumatica staff, was that "L Series tier will give you 6 concurrent web service API requests". Tier naming has changed since, so read that thread as the failure mode rather than as current numbers.

The practical translation for a buyer is short. On Acumatica, users are free and transactions are not, so your storefront consumes your ERP entitlement and traffic growth is a sizing event you should price into the business case at the start. Every mature Acumatica commerce architecture we see reaches the same answer: cache the things that do not change per buyer, call live only for the price, the availability and the credit, and keep the call count per page view in single digits.

It means you cannot size a real-time integration against Cin7 Core from public information, and you should ask Cin7 for the numbers in writing before you commit to an architecture that depends on them.

Cin7’s own article, Connecting to the Cin7 Core API, states that "API limits are applied on per API Application basis" and then gives no figure: no requests per minute, no concurrency, no burst allowance, no documented behaviour on throttle. A vendor confirming that limits exist while withholding the number is a specific and unusual position, and it is worth naming rather than glossing over. It is not the same as having no limits.

The authentication model compounds it. Cin7 Core authenticates with two static headers, api-auth-accountid and api-auth-applicationkey, generated inside the application, and the article makes no mention of OAuth. The account ID differs per company you have access to, and you can create multiple API applications on one account. That last detail is the useful one: because limits are applied per API application, giving the storefront its own application keeps it from competing with your reporting jobs and your 3PL feed for the same undisclosed budget.

The design conclusion follows directly. On Cin7 Core, build for batch syncA batch sync moves data between systems on a schedule, for example every night or every 15 minutes, rather than the moment something changes. It is simpler to run than event-driven integration and it is always at least slightly out of date. and cache aggressively, use a separate API application per integration, and treat any live per-page-view call to Cin7 as a risk you have to prove rather than a default you can assume. That is a workable architecture and plenty of Cin7 storefronts run on it. It is just not the architecture you would choose if the numbers were published and generous.

SOAP web services, on a published schedule, and it forces any integration you own or commission to be on SuiteTalk REST before the 2028.2 release. NetSuite’s own documentation is unusually clear about this, which makes it easy to plan around.

The documented sequence is three steps. "The 2025.2 SOAP endpoint is the last planned SOAP endpoint and any later SOAP endpoints would be released only as necessary to meet business, technical, or other significant requirements." Then, "with the 2027.1 release, only the 2025.2 endpoint will be supported". Then, "with the 2028.2 release, SOAP will no longer be available in NetSuite and existing SOAP integrations with NetSuite will stop working". NetSuite names the replacement: "SuiteTalk REST web services is the technology intended to replace SOAP. All newly built integrations should use REST web services with OAuth 2.0 for authentication."

For a B2B commerce project starting now, that has one practical consequence and it is a procurement one. Ask any connector vendor or integrator which protocol their NetSuite integration uses, and get the answer in writing. A SOAP-based connector bought in 2026 has a known replacement date, and paying twice for the same integration is the avoidable outcome here.

Because it removes a line item and an owner from the project, and on a mid-market budget that is not a small change. Microsoft builds the connector, ships it inside Business Central, and states that "the app is preinstalled for all new sign-ups and trials". Its FAQ adds that "the organization must have both a Business Central license and a Shopify license to use the connector", which is to say there is no third bill.

Compare that with what the same capability costs elsewhere. On NetSuite you are licensing SuiteCommerce as a module or buying a third-party connector. On Cin7 Core the Shopify integration is included but the B2B portal is a per-portal add-on. On Acumatica the connector is first-party and free, so Acumatica and Business Central are alike on this row and both are ahead of NetSuite on it.

Three limits are published and belong in the same breath, because a connector that does not fit your deployment is worth nothing. Microsoft states the Shopify connector "isn’t available for on-premises deployments", that it "doesn’t work for Embed App" where the client URL uses the bc.dynamics.com format, and that it "doesn’t work with other Dynamics 365 applications, like Dynamics 365 Sales or Dynamics 365 Supply Chain Management". If you run Business Central on premises, this advantage does not apply to you at all.

Decide, field by field, what has to be live and accept a staleness budget for everything else. This is the single design decision that keeps an ERP-backed storefront inside its API ceiling on every one of these four platforms, and it costs nothing to make early.

Write it down as a table your integrator has to build against, because "real time" in a requirements document means whatever the reader wants it to mean, and the argument surfaces during user acceptance testing when it is expensive.