NetSuite integration concurrency and governance limits, with the numbers

Two limits, and they work differently

NetSuite has no requests-per-minute limit of the kind most APIs have. It has two separate limits, and an integration runs into them in different places.

Concurrency is counted per account. It is the number of API requests NetSuite is processing at the same moment. Every integration that talks to the account draws from the same pool: the store integration, the warehouse system, the EDI provider, the reporting tool.

Governance units are counted per script execution. Every SuiteScript API call costs a fixed number of units, and each script type has a budget. A script that runs out is stopped in the middle of its work.

A long request makes both worse at once. A RESTlet that processes 80 orders in one call uses most of its unit budget and holds one concurrency slot for the full duration.

The numbers

The figures below were read from Oracle's NetSuite documentation on October 3, 2026.

Concurrent requests per account

The limit depends on the service tier of the account. Each SuiteCloud Plus license adds 10. Oracle documents the table under concurrency governance limits.

These tiers apply to contracts from June 2020. Older contracts use numbered tiers: shared and tier 3 have a base limit of 5, tier 2 has 10, tiers 1 and 1+ have 15, tier 0 has 20. A sandbox matches production. Development and partner accounts always have 5, whatever the number of licenses.

A request over the limit is rejected, not queued. What comes back depends on the interface:

The REST web services response looks like this:

{
  "title": "Bad Request",
  "status": 429,
  "o:errorCode": "USER_ERROR",
  "o:errorDetails": [
    {
      "detail": "Concurrent request limit exceeded. Request blocked.",
      "o:errorCode": "CONCURRENCY_LIMIT_EXCEEDED"
    }
  ]
}

Governance units per script type

Oracle lists the budgets under script type usage unit limits.

A map/reduce script has no limit on the whole run. Each function invocation has its own budget, and a job yields and reschedules itself after 10,000 units. That is the script type for work on tens of thousands of records.

Governance units per call

The cost of a call depends on the record type. A sales order, an invoice and an item fulfillment are transaction records. A customer and an item are standard non-transaction records. The full list is in Oracle's SuiteScript API governance table.

The often quoted figures of 5 units for a load and 10 for a save are the costs for a customer or an item. A sales order costs twice that.

What it means for an order sync

Take a RESTlet that receives orders from a store and creates sales orders. Per order it does four things:

5,000 units divided by 50 is 100 orders per RESTlet call, with no units left over. A new customer adds 15 units (create 5, save 10). A batch of 20 orders per call uses 1,000 to 1,300 units and leaves room for the orders that need more work.

The same batch decides the throughput under the concurrency limit. Assume one order takes 2 seconds to create, because user event scripts and workflows run on every save:

• One order per request, 5 slots: 5 orders every 2 seconds, 150 orders a minute, and the account has no slot left for anything else.
• 20 orders per request, 2 slots: 40 orders every 40 seconds, 60 orders a minute, with 3 slots free for the warehouse and reporting integrations.

Reads work the other way around. Loading 60,000 items one by one with record.load costs 300,000 units, the budget of 60 RESTlet calls. The same read through SuiteQL on the REST interface returns up to 1,000 rows per page: 60 requests. One SuiteQL query returns at most 100,000 rows, so a larger catalog is split by a range on the internal ID. Bulk reads go through SuiteQL; writes that need lookups and defaults go through a RESTlet that does the work in one request. How to turn these figures into a duration for a full run is in working out integration throughput.

What happens when you hit the ceiling

NetSuite does not hold a request that exceeds the concurrency limit. It rejects it, and the caller has to send it again. Oracle's own guidance is to retry after a delay, to increase the delay on each further attempt, and to avoid retrying from several threads at the same moment, since that creates a new peak.

There are three ways to get more room:

1. A SuiteCloud Plus license. Each one adds 10 concurrent requests. A Standard account goes from 5 to 15.
2. Moving work out of the peak. A full item export at 02:00 competes with nothing. The same export at 10:00 competes with order entry.
3. Fewer, larger requests. 20 orders in one RESTlet call hold one slot. 20 separate calls hold up to 20.

The documentation of standard connectors and iPaaS platforms gives a fourth answer to throttling: a smaller page size and a longer schedule interval. That keeps the flow running and makes every record arrive later. The mechanics of retries and growing pauses are covered in API throttling, 429s and backoff.

A script that runs out of governance units is a different failure. It stops with SSS_USAGE_LIMIT_EXCEEDED after some records are saved and before others. The RESTlet has to count its own remaining units, stop at a safe point and report which orders it has finished, so the caller resends only the rest. What a failed run looks like from the outside is in what happens when an integration fails.

Peak days

A queue set up for a normal Tuesday and one set up for Black Friday are different queues. A store that takes 50 orders an hour on a Tuesday and 500 an hour on its peak day sends ten times the requests into the same 5 slots, while the warehouse integration posts ten times the fulfillments into that same pool.

At 2 seconds per order, 500 orders are 1,000 seconds of request time in an hour. That fits in one slot. The problem is the stock export that runs every 15 minutes: 60 SuiteQL pages at 3 seconds each is 180 seconds on one slot, or 36 seconds on all five. Run on all five, every order request in those 36 seconds is rejected.

The integration therefore gets a fixed share of the account limit, below the limit itself. On a Standard account: 2 slots for orders, 1 for stock reads, 2 left for the other integrations. The queue enforces that share, so a burst of orders waits a few seconds in the queue and is never rejected by NetSuite. The store side has its own budget, described in Shopify API rate limits.

What this means for your integration

We build the NetSuite side around these numbers. Orders go through a queue with a fixed number of concurrent requests, RESTlets work in batches that stay inside 5,000 units, bulk reads use SuiteQL, and a rejected request is retried with a growing pause. Nothing is dropped when NetSuite answers with SSS_REQUEST_LIMIT_EXCEEDED: the order stays in the queue, and the dashboard log shows when it was sent, rejected and accepted.

The account-specific parts are on the NetSuite integration page and, for Shopify stores, on Shopify NetSuite integration. Which order fields move and which system owns them is on orders, customers and shipping. Tell us your service tier and which integrations already use the account, and we work out how many slots the new integration gets.