Notes
How long does a full sync take? Working out integration throughput
The duration of a sync is the number of records, times the calls per record, divided by the rate limit of the slowest system. 15,000 items at one call each and 60 requests a minute is 250 minutes. The same 15,000 items in pages of 60 is 250 calls and a little over 4 minutes.
Updated
The sum
A full sync takes as long as this sum says:
duration = records x calls per record / rate limit
15,000 items x 1 call / 60 calls per minute = 250 minutes = 4 h 10 min
15,000 items x 2 calls / 60 calls per minute = 500 minutes = 8 h 20 min
Three numbers go in. The record count is known. The rate limit is in the documentation of the system. The calls per record is the one that is usually guessed too low: an item that needs one call for its data, one for its stock per warehouse and one for its price list is three calls, and 15,000 items are then 45,000 calls and 12.5 hours.
The sum has to be made for both ends. An integration reads from one system and writes to another, and the slower end sets the duration.
Four kinds of limit
Systems limit API traffic in four ways. Each enters the sum differently.
| Kind of limit | Example | How it enters the sum |
|---|---|---|
| Requests per time | Exact Online: 60 calls per minute per company. Shopify REST Admin API: 2 requests per second | calls / rate |
| Cost budget | Shopify GraphQL Admin API: 100 points per second on a standard plan, 10 points per mutation by default | calls x cost / rate |
| Daily cap | Exact Online: 5,000 calls per company per day | calls / cap, in days |
| Concurrency | NetSuite: 5 requests at the same time on the Standard tier | records per request x slots / seconds per request |
The figures in this table were read from the vendors' documentation on October 3, 2026. The details per system are in Shopify API rate limits and NetSuite concurrency and governance limits.
A daily cap changes the unit of the answer. 15,000 items at one call each against 5,000 calls a day is three days, whatever the rate per minute. And those three days assume that nothing else uses the same budget: no orders, no price updates.
A concurrency limit has no rate at all. Throughput follows from how long one request takes and how many records it carries. With 5 slots, 3 seconds per request and one record per request, that is 100 records a minute. With 50 records per request at 10 seconds each it is 1,500 a minute.
A full sync of 15,000 items, twice
An ERP with a limit of 60 requests a minute holds 15,000 items. The store accepts 2 requests a second on its REST interface, or 100 cost points a second on GraphQL. The same sync, built two ways:
| Step | One record per call | Pages and batches |
|---|---|---|
| Read from the ERP | 15,000 calls at 60 a minute: 250 min | 250 pages of 60 records at 60 a minute: 4 min 10 s |
| Write to the store | 15,000 calls at 2 a second: 7,500 s, 125 min | 60 calls of 250 records, 600 points at 100 a second: 6 s |
| Total | 375 min, 6 h 15 min | under 5 min |
The limits are the same in both columns. The difference is the number of records per call: 60 on the read, 250 on the write. Both figures are documented maximums. Exact Online returns 60 records per page on its REST API and up to 1,000 on its bulk and sync endpoints. Shopify accepts 250 items in an input array.
Whether pages and batches are available depends on the endpoint, and it has to be checked per field. An ERP can return items in pages of 1,000 and still require a separate call per item for the stock per warehouse or for the customer price. If that is the case for 15,000 items, the read is back at 250 minutes for that one field. This is the most common reason a sync that was estimated at minutes runs for hours.
In CSV terms the same thing looks like this. A supplier file is one request for all records:
sku;stock;next_delivery
KB-2210;140;2026-10-14
KB-2211;0;2026-11-02
KB-2214;32;
15,000 lines arrive in one download. The read side costs seconds, and the whole duration sits on the write side.
Polling: when the run is longer than the interval
A scheduled sync has two durations: how long one run takes and how often it starts. The run has to fit inside the interval.
There are standard connectors that scan stock in portions of 10 products every 5 minutes. That is 120 products an hour:
| Catalog | Portions of 10 | One full round |
|---|---|---|
| 1,000 products | 100 | 500 min, 8 h 20 min |
| 5,000 products | 500 | 2,500 min, 41 h 40 min |
| 20,000 products | 2,000 | 10,000 min, 6 days 22 h 40 min |
At 1,000 products a stock change made at 09:00 reaches the store after 17:00 in the worst case. At 20,000 products the store shows stock that is up to a week old. Nothing fails in such a setup and no error is logged. The store sells items that went out of stock three days ago.
The fix is to stop moving records that did not change. If 3% of a 15,000 item catalog changes on a day, that is 450 records. A run that asks the ERP for everything modified since the previous run moves those 450 and leaves the other 14,550 alone. One full comparison a night catches what the change filter missed. Which flows need minutes and which can wait for the nightly run is in real time versus batch.
A catalog of 50,000 variants that is read in full and compared field by field every 15 minutes is the same problem at a larger size: 96 full reads a day to find a few hundred changes.
The peak hour
Orders set a different requirement from stock: an order has to reach the ERP before the warehouse starts picking, on the busiest day as well.
A store that takes 50 orders on a normal day and 500 in the busiest hour of its peak day has two different loads:
| Normal day | Peak hour | |
|---|---|---|
| Orders | 50 a day | 500 an hour |
| Calls at 4 per order | 200 a day | 2,000 an hour, 33 a minute |
| Share of 60 calls a minute | under 1% | 56% |
| Share of 5,000 calls a day | 4% | 40% per hour |
The 4 calls per order are: find the customer, create the customer when new, create the order, read back the order number. At 33 calls a minute for orders, 27 a minute remain for everything else. A stock run that wants 60 a minute at the same moment pushes both over the limit, and the API answers with a 429.
Against a daily cap the peak is worse. 2,000 calls an hour use a cap of 5,000 in two and a half hours. After that every call is refused until the next day, orders included. An integration on such a system needs a budget per flow: orders first, stock from what is left, the full comparison at night.
A queue set up for a normal Tuesday handles 200 calls a day. The same queue on the peak day has to hold several hundred orders while the limit lets 60 calls a minute through, and deliver every one of them in order. What happens to the messages that wait is in API throttling, 429s and backoff.
Headroom
Published limits are ceilings, and they move. Shopify states that it can lower its rate limits for a short time to protect the platform. NetSuite shares its concurrency limit across every integration on the account, so the room left depends on what the others are doing.
A sync planned at 100% of the limit is throttled on the first busy day. Planning at a share of the limit, and measuring the actual duration of every run, shows the trend before it becomes a backlog: a run that took 4 minutes in March and takes 11 in September will not fit its 15-minute interval by December.
Platform quotas and a BigCommerce sync example
Every API limits how many requests you can make per second, per minute or at once. That limit sets how long a run takes, and so how current your store is.
| System | Limit | What it means for the integration |
|---|---|---|
| Shopify | GraphQL cost points restored at 100 a second, 200 on Advanced, 1,000 on Plus | large reads and writes go through bulk operations, not single queries |
| BigCommerce | 150 requests per 30 seconds on Standard and Plus, 450 on Pro; shared by every app on the store | other apps take from the same quota |
| NetSuite | 5 concurrent requests on Standard, 15 on Premium, 20 on Enterprise and Ultimate, plus 10 per SuiteCloud Plus license | every integration on the account shares the same slots |
| Business Central | 6,000 OData requests per 5-minute window and 5 concurrent requests, per user | heavy flows are spread over separate users |
| QuickBooks Online | 500 requests a minute per company, 10 a second per company and app | a 429 means waiting 60 seconds |
The numbers were checked on October 3, 2026 in the vendors' documentation, among them BigCommerce's rate limits and Shopify's rate limits.
A worked example. A distributor has 15,000 SKUs on a BigCommerce Standard store, and the integration reads them from the store to compare stock with the ERP. 150 requests per 30 seconds is 300 requests a minute.
- One SKU per request. 15,000 requests divided by 300 is 50 minutes for one run.
- Only what changed. With 600 changes since the last run it is 600 requests: 2 minutes.
- 250 SKUs per page. 15,000 divided by 250 is 60 requests: 12 seconds.
- With other apps on the store. BigCommerce shares the quota between all apps. If a review app and a marketing app use 100 of the 150 requests per window, the integration has 50, which is 100 a minute. One request per SKU then takes 150 minutes.
The integration combines the second and third: per run only the changes, in the largest pages the API allows, with a queue that spreads requests over the window. When it does reach the limit, BigCommerce answers with a 429 and tells the client how long to wait:
HTTP/1.1 429 Too Many Requests
X-Rate-Limit-Time-Window-Ms: 30000
X-Rate-Limit-Time-Reset-Ms: 15000
X-Rate-Limit-Requests-Quota: 150
X-Rate-Limit-Requests-Left: 0
The integration reads X-Rate-Limit-Time-Reset-Ms, waits 15 seconds and continues where it stopped. The sum for your own numbers is in integration throughput; how each vendor throttles is in API throttling and backoff.
Account, user and store quotas
Three differences that shape an integration's design. NetSuite counts concurrency per account, so an integration shares its 5 slots on a Standard account with every other integration and script calling in. Business Central counts per user, so separate users let heavy flows run side by side. BigCommerce counts per store, so the apps your store already runs set how much quota is left.
What this means for your integration
We make this sum before we build: record counts, calls per record for every field you need, the limits of both systems, and the peak hour. The result decides the design: which flows run on webhooks, which on a schedule, the page and batch sizes, and how the budget is split between orders and stock. After go-live the dashboard shows the duration and record count of every run, so growth in the catalog is visible in the numbers.
The stock flow, where this sum matters most, is described on stock and availability. The overview of all flows is on integrations, and the store to ERP setup as a whole on ecommerce ERP integration. Send us your record counts and the two systems, and we return the sum for your full sync and your peak hour.
Frequently asked questions
How long does a full sync take?
Multiply the number of records by the calls each record needs and divide by the rate limit. 15,000 items at one call each against 60 requests a minute is 250 minutes. With 60 records per page it is 250 calls and 4 minutes 10 seconds. The answer for your systems depends on the page size the API allows and on which of the two systems is slower.
Why is the first sync slower than the daily one?
The first sync moves every record. After that a run only moves what changed since the last run. If 3% of 15,000 items change on a day, that is 450 records. At one call each and 60 requests a minute those take 7.5 minutes, where the full set took 250.
What happens when a sync takes longer than its schedule?
The next run starts before the previous one has finished, or waits for it. In both cases the data in the target falls further behind with every cycle. A scan of 10 products every 5 minutes needs 8 hours 20 minutes for 1,000 products, so a stock change at 09:00 can reach the store after 17:00.
Does a higher plan or license fix slow sync?
It raises the ceiling. Shopify Plus gives 1,000 cost points per second where a standard plan gives 100, and one NetSuite SuiteCloud Plus license adds 10 concurrent requests. The call pattern has the larger effect: 250 records per call where there was one is a factor of 250, and it works on every plan.
How many orders per hour can an integration handle?
Count the calls per order and compare them with the limit of the ERP. An order that needs 4 calls, at 500 orders an hour, is 2,000 calls an hour or 33 a minute. Against a limit of 60 a minute that fits, with 27 calls a minute left for stock and prices. Against a daily cap of 5,000 calls it is used up in two and a half hours.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase