Most NetSuite integrations sync once a day because of how they're built, not because NetSuite makes them slow. NetSuite's platform enforces real, published limits on how many requests an integration can run at once, and a naive integration hits that ceiling constantly at real order volume. The common fix is to stop trying to sync often. This guide covers exactly what those limits are, why the once-a-day pattern exists, and what a connection built around it instead looks like.
Jump to What You Need
| If You Want To… | Jump To |
|---|---|
| Understand NetSuite's real concurrency and rate limits | NetSuite's Actual Limits |
| Know why most integrations only sync once a day | Why Batching Became the Default |
| See the difference between a synchronous and asynchronous call | Synchronous vs Asynchronous, the Part That Matters |
| Understand RESTlets specifically, and why they cap out fast | RESTlets and Their Separate Limit |
| See how InfiPlex actually connects to NetSuite | How InfiPlex Runs NetSuite Differently |
What Are NetSuite's Actual API Limits?
NetSuite governs integrations two ways at once: how many requests can run at the same time, and how many requests are allowed in a given time window. Both are enforced account-wide, across every integration touching that account, not per connection.
| Limit type | What it means |
|---|---|
| Concurrency | How many requests can be in flight at the exact same moment. Base allowance depends on service tier, and each additional SuiteCloud Plus license adds to it. |
| Rate | How many total requests are allowed within a rolling window, typically measured per minute and per 24 hours, independent of concurrency. |
| Shared across API types | SOAP web services, REST web services, and RESTlets all draw from the same account-wide concurrency pool. Using a different API surface doesn't create a separate allowance. |
| What happens over the limit | A 429 error, request limit exceeded. The call fails outright rather than queuing. |
This has been true since Oracle introduced account-level concurrency governance in 2017. Before that, integrations could run largely unregulated. Since then, every integration touching a NetSuite account, regardless of how it's built, shares one governed pool.
Why Do Most NetSuite Integrations Only Sync Once a Day?
The limits above are entirely survivable at moderate volume. They become a real constraint when an integration is "chatty": making one API call per order, per SKU, or per inventory update, rather than grouping work together. A brand with a few hundred orders a day rarely notices. A brand with a few thousand orders a day, spread across a real order queue with inventory updates layered on top, can burn through the concurrency allowance in minutes.
The common fix in the integrator world isn't to solve the underlying request pattern, it's to stop making the calls as often. If a sync runs once a day instead of continuously, the total number of requests over 24 hours stays low enough to avoid hitting the ceiling, even if each individual sync is still built the same chatty way. That is a real, working solution to the concurrency problem. It also means inventory and order data on the client's side is, by design, up to a full day stale.
A publicly documented example of the alternative: a high-volume NetSuite integration handling more than 100,000 sales orders in a single day used over 40 concurrent connections at once, deliberately sized against the account's licensed concurrency allowance rather than working around it. That is the other way to solve the same problem, provision and architect for the actual volume, instead of syncing less often.
Synchronous vs Asynchronous: The Distinction That Actually Matters
A standard, synchronous call to NetSuite holds its concurrency slot for the entire time the work takes. If saving a sales order takes five seconds, that slot is occupied for five seconds, unavailable to anything else the integration is trying to do at the same moment. Do this one record at a time, across thousands of records, and the concurrency ceiling arrives fast regardless of the account's tier.
NetSuite also supports an asynchronous pattern: a request is submitted, NetSuite responds immediately to confirm it was received, and the actual processing happens afterward in a separate queue built for background work. That queue draws from a different resource pool than the live concurrency allowance, so it does not compete with real-time calls for the same slots. The tradeoff is that background processing isn't instant, so this pattern fits large batch operations well and fits a single, time-sensitive order poorly.
The practical implication: an integration built entirely around synchronous, one-record-at-a-time calls will hit the ceiling at volume no matter how the sync schedule is tuned. An integration that separates high-volume batch work from real-time, order-level work can run both without either one starving the other.
RESTlets and Their Own Separate Limit
RESTlets are custom endpoints built on NetSuite's scripting layer, a common way to build tailored integration logic directly inside NetSuite. They carry their own additional constraint on top of the account-wide concurrency pool: a per-user cap on simultaneous RESTlet calls, separate from and stricter than the broader account allowance.
That extra ceiling exists specifically for RESTlets. An integration built on NetSuite's standard REST web services, authenticated machine-to-machine rather than through custom scripted endpoints, is not subject to that particular per-user RESTlet cap. It still shares the same underlying account-wide concurrency pool as every other integration, since that governance applies across API types, but it avoids the additional, narrower ceiling that RESTlet-based integrations carry on top of it.
How InfiPlex Actually Connects to NetSuite
InfiPlex connects to NetSuite over REST web services using machine-to-machine authentication, not RESTlets. Legacy SOAP connectivity exists for backward compatibility but is being phased out in favor of REST M2M as the primary path. That choice means InfiPlex isn't subject to the separate, stricter per-user RESTlet ceiling described above, though it remains, like every NetSuite integration, governed by the account-wide concurrency and rate limits NetSuite applies to all connected systems.
On cadence: InfiPlex syncs NetSuite order and inventory data continuously throughout the day, roughly every 15 minutes, all day, every day. Some specific data types, inventory pulls in particular, are handled in batches within that cycle rather than record-by-record, a deliberate choice to keep high-volume operations efficient rather than a limitation.
On top of the standing cycle, InfiPlex includes an on-demand path: a user can select one or more specific orders inside NetSuite and pull them into InfiPlex immediately, rather than waiting for the next scheduled interval. That matters for the case a 15-minute cycle doesn't cover, an order that needs to move right now, not at the next check-in. The same push-and-pull works for shipments in the other direction: once an order ships, tracking and fulfillment data move back into NetSuite the same way, not just orders moving one way in.
Both orders and shipments move in either direction between the two systems, not a one-way feed. NetSuite orders, once in InfiPlex, sit alongside every other channel in the same inventory pool, with the same routing rules, EDI documents, and 3PL connections available to them as to any marketplace order.
See the InfiPlex NetSuite integration | Get a free demo
NetSuite Integration Questions
Why do NetSuite integrations often only update once a day?
NetSuite enforces account-wide concurrency and rate limits, shared across every integration touching the account. A chatty integration, one API call per order or per SKU, hits that ceiling quickly at real volume. Reducing sync frequency to once a day is a common, working way to stay under the limit without redesigning the underlying request pattern.
What is NetSuite concurrency governance?
It's NetSuite's account-wide limit on how many API requests can run at the same moment, with a base allowance set by service tier and additional capacity added per SuiteCloud Plus license. It applies across SOAP, REST, and RESTlet calls combined, not per integration.
Do RESTlets have their own limit separate from the account-wide one?
Yes. RESTlets carry an additional per-user cap on simultaneous calls, on top of the account-wide concurrency pool. Integrations built on standard REST web services with machine-to-machine authentication instead of RESTlets don't carry that particular extra ceiling, though they still share the underlying account-wide limit every NetSuite integration operates within.
Does InfiPlex use RESTlets for NetSuite?
No. InfiPlex connects over REST web services with machine-to-machine authentication. Legacy SOAP connectivity remains for backward compatibility but is being phased out in favor of REST M2M.
How often does InfiPlex sync with NetSuite?
Continuously throughout the day, roughly every 15 minutes, rather than a single daily batch. Inventory pulls specifically are handled in batches within that cycle for efficiency. A separate on-demand feature also lets a user select specific NetSuite orders and push them into InfiPlex immediately, without waiting for the next scheduled cycle.
Can I pull a specific NetSuite order into InfiPlex right away instead of waiting for the sync?
Yes. NetSuite users can select one or more orders directly and pull them into InfiPlex on demand, independent of the standing sync cycle. Shipment and tracking data push back to NetSuite the same way once an order ships.
Need Something This Doesn't Cover?
Contact Us and we'll take a look. Support is included with every InfiPlex plan.
