NetSuite Concurrency Limits: How Much Integration Traffic Your Account Can Handle

The NetSuite concurrency limit caps how many integration requests can be in flight at the same moment. It is not a requests-per-minute rate limit. Integrations in the account share it, apart from a short list of Oracle internal applications.

Your limit depends on your service tier and your SuiteCloud Plus licenses. When integrations ask for more than the limit allows, NetSuite rejects the extra requests. That often happens at peak: a promotion, a month-end close or a busy AI client.

This guide covers the numbers by tier, what draws on the limit, what failure looks like, and a worksheet for sizing your own peak. The sizing method is ERP Peers’ own, not an Oracle formula.

What the concurrency limit is

Concurrent means in flight at once. A request that has been sent and not yet answered holds one slot. When it finishes, the slot frees up. The limit is the number of slots your account has.

The mechanism is called concurrency governance. It governs simultaneous requests rather than total volume. A thousand short requests spread across a minute can fit comfortably. Twenty slow requests sent together can fill a small account.

What it is separate from

SuiteCloud Plus also raises other capacity: script processors, CSV import queues, asynchronous search queues and REST asynchronous processors. Those are separate settings from the concurrency limit. The table in the SuiteCloud Plus section lists them.

Some Oracle internal applications are exempt. Their requests do not count toward the limit, and they do not appear in Concurrency Monitor or Integration Governance data. At the time of writing the list is NetSuite Connector, NetSuite for Outlook, NetSuite Point of Sale and SuiteProjects Pro, and it can change.

How many requests your account can run at once

The base limit comes from your service tier. The service tier also sets users, storage and monthly transaction lines, so read the two together.

Earlier tiers have different base limits:

• Shared and tier 3: 5.
• Tier 2: 10.
• Tiers 1 and 1+: 15.
• Tier 0: 20.

Worked example: tier 1 with five licenses is 15 + 5 × 10 = 65.

How the limit applies by account type:

• Production: the base plus 10 for each SuiteCloud Plus license.
• Sandbox: it matches your production limit.
• Development and partner accounts: always 5, and the figure does not grow with licenses.

You can read the figure on the Integration Governance page, under Setup, Integration, Integration Management. The menu path can vary by release.

What SuiteCloud Plus changes

SuiteCloud Plus is a paid add-on license that raises integration capacity. Licenses are not included in any service tier. You buy them separately, up to a maximum that depends on the tier. This guide does not quote prices.

The arithmetic is the same on every tier. A Premium account with two licenses has 15 + 2 × 10 = 35. An Ultimate account at its twelve-license maximum has 20 + 12 × 10 = 140.

Licenses also raise capacity that is not part of the concurrency limit:

Questions to ask your Oracle account manager:

• What is the current term for each license?
• What is the maximum number for our tier?
• When would an added license take effect?
• How does it renew?

What draws on the pool in your account

Most accounts do not have one integration. They have a storefront, a warehouse system, payroll, a bank feed and increasingly an AI client. All of them draw on the same pool. This table maps each common source to the limit.

How authentication affects per-user limits

Request-level credentials and login keep per-user limits for SOAP. Token-based SOAP and RESTlets have no per-user limit when concurrency governance is enabled, so one user can send parallel SOAP requests up to the account limit.

Sessions authenticated with SuiteSignOn are governed per user and per account. The token-based and RESTlet benefit applies only when governance is enabled, and SOAP Web Services Preferences shows whether it is.

Older setups guaranteed 10 concurrent SOAP requests to each designated web services user with a SuiteCloud Plus license. That guarantee no longer applies, because those requests now draw from the shared pool.

If you are moving integrations to OAuth 2.0, the TBA migration guide covers which are affected. Check each one’s concurrency settings as part of the move.

Per-integration limits

An administrator can give one integration a fixed share of the pool. This protects a critical flow, or caps an application you do not control that sends occasional bursts. The minimum unallocated limit is 1, and any share you allocate is unavailable to every integration without one.

Best practice is a single account limit with no individual allocations, unless you have a clear reason. If your tier or license expires, the account limit resets to its default, and the administrator is warned if allocations exceed it.

The AI Connector Service

The NetSuite AI Connector Service always sits inside the account limit. With a total limit of five and two slots assigned to a REST integration, it can use only the remaining three. When it goes over, the AI client sees a Too Many Requests error and has to retry.

A prompt that calls an MCP tool is typically preceded by additional protocol requests. Count those when you size the account, because several people prompting at once can add up.

Celigo connections

Celigo gives every NetSuite connection its own concurrency setting and advises aligning it with your NetSuite limit. With several connections, we recommend dividing that limit among them and the other callers, so do not set each one to the full account figure. Celigo suggests a second connection once one connection needs more than 25 concurrent requests.

If your flows run on Celigo, check these settings on both sides. Our Celigo integration page describes how ERP Peers supports them.

What happens when you exceed the limit

NetSuite rejects requests over the limit. What the caller sees depends on the integration type.

Error codes by integration type

Retry logic that does not make it worse

Every client has to retry rejected requests. Wait before the first retry and lengthen the delay on later attempts. Do not synchronize retries across threads or applications, because that creates artificial peaks. For interactive screens, retry in the background.

We recommend three habits. Randomize the delay. Cap the number of attempts. Make sure a retried write cannot create a duplicate record.

Retrying after a timeout or no response is the risky case, because the first write may already have succeeded. Use an external ID, or look the record up before creating it, so a retry cannot create a second copy.

Symptom to cause

If requests are slow rather than rejected, the problem sits elsewhere. Our guide to speeding up a slow NetSuite instance covers the usual suspects.

How to see how close you are

• Concurrency Monitor: shows your limit, estimated peak concurrency, how often you came close to the limit, how often you went over and the error rate. The peak is an estimate and can differ from the Concurrency Details dashboard.
• Integration Governance page: shows the account limit and what is unallocated.
• REST governanceLimits operation: lets an integration read the limit available to it, so it can size its own threads. It returns results only for an administrator login.
• SOAP Web Services Preferences: confirms concurrency governance is switched on for the account.
• Exempt applications: their requests do not appear in this data.

For what to watch beyond concurrency, see our guide to integration monitoring and error handling.

How to size your peak concurrency

Oracle gives no formula for turning peak load into a license count. This is the estimate ERP Peers suggests.

Why your peak can be higher than the estimate

The formula gives an average over the window you measured. Actual peaks can run above it for five reasons.

• Bursts: requests arrive in clusters inside the minute, not evenly.
• Retries: rejected requests come back and add load.
• Scheduled overlap: flows that start on the hour all start together.
• Latency at peak: requests slow down when the system is busiest, so each holds its slot longer. A REST request that runs longer than 15 minutes times out, so a few very long requests can hold slots for a long time.
• Rejections hide demand: rejected requests may not hold slots, so rates measured during them understate it.

Add a safety margin on top of the estimate and write it down.

Capacity worksheet

Fill this in for the busiest hour you can find in your logs. Use the same hour for every row, so overlap is counted.

1. List every caller: each integration, each flow on Celigo or another iPaaS, each script that calls out, and the AI client.
2. Take the peak requests per minute for each caller in that hour, counting first attempts only. Integration logs, iPaaS run history and Concurrency Monitor are the usual sources. A timed-out request may still be running, so keep retries inside your margin.
3. Take the average request duration in seconds, and note the slowest 5% as a stress case.
4. Multiply the two and divide by 60. Repeat with the stress duration. If the stress figure is a large part of the limit, treat that caller as at risk.
5. Add the rows, then add your safety margin.
6. Compare the total with the limit on your Integration Governance page.

Three illustrative scenarios

Scenario 1: an ecommerce order spike

A Premium account with one license has a limit of 25. The storefront, the warehouse system and an inventory sync all run during a promotion. The scenario assumes an iPaaS or custom integration, because NetSuite Connector requests are exempt.

With the margin the estimate is 24 against a limit of 25, which is too tight. If the promotion lifts order import by a third, the estimate reaches 22, or about 28 with the margin.

Moving the inventory sync to a quieter window frees 6 slots with no license, but check that a later sync does not leave stock stale during the promotion. Lower order-import parallelism or batched inventory updates are alternatives. On the decision path below, this account stops at step 4.

Scenario 2: month-end batch overlap

A Standard account with its one license has a limit of 15. At close, four jobs start at the same time.

The estimate is 16 against a limit of 15, and Standard accounts can add only one license. Running the reporting extract after the other three jobs finish brings the peak to 10, which uses two-thirds of the limit, or about 13 of 15 with the margin. The cost is a later extract. On the decision path below, this account stops at step 3.

Scenario 3: AI Connector activity alongside integrations

An Enterprise account with no licenses has a limit of 20. Integrations use 11 slots at peak. Four people are using an AI client at once. We assume 3 requests in flight per person as a cautious figure, counting protocol requests. This table uses that in-flight figure directly instead of rate and duration.

The total is 23 against 20, or about 29 with the margin, so the AI client can see Too Many Requests when integrations peak. Reserving a fixed share for the AI Connector Service only re-divides a pool that is already short. The options are to keep AI use out of the integration peak, reduce integration load, or add one license for a limit of 30.

On the decision path below, keeping AI use out of the peak is step 4. If that is not practical, the account reaches step 6, is below its Enterprise license maximum, and adds one license, which leaves a thin margin.

Should you add licenses or redesign?

Answer in order. Stop at the first step that fixes the errors, then re-measure. If errors continue, go to the next step.

1. Do callers receive concurrency error codes, or does Concurrency Monitor show over-limit events? No: concurrency is probably not the problem, so check client-side throttling and request latency. The monitor’s peak is an estimate and it leaves out exempt applications, so rely on the error codes as well. Yes: go to 2.
2. Do rejections climb in bursts after the first failures? Yes: fix the retry logic and re-measure. If errors continue, or if you answered No: go to 3.
3. Do rejections happen only when scheduled jobs start together? Yes: stagger the jobs and re-measure. If errors continue, or if you answered No: go to 4.
4. Does one caller account for a large share of your estimated peak, or can a heavy caller, including AI use, be moved off-peak? Yes: lower that caller’s concurrency, batch its requests or move it off-peak, then re-measure. Reserve a share only to protect a critical flow. If errors continue, or if you answered No: go to 5.
5. After steps 1 to 4, does your worksheet total, with margin, still exceed the limit? No, and errors have stopped: you have enough capacity today, so keep the readiness checklist and re-measure after the next peak. No, but errors continue: the worksheet is probably missing something, such as a caller left off the list, a fixed allocation set below that integration’s own peak, a per-user SOAP limit, retries or a slow request at peak. Fix the inputs and re-measure. Yes: go to 6.
6. Are you below your tier’s license maximum? For older tiers, ask your account manager. Yes: add SuiteCloud Plus licenses, sized from the worksheet. No: redesign with batching, queues and fewer chatty calls, then discuss a higher tier where one exists. A development or partner account is always No, because its limit is fixed at 5.

Reduce demand before buying capacity

These usually cost less than a license.

• Batch records into fewer requests, and avoid record-by-record reads.
• Queue work and cap the number of workers, so an integration never sends more than its share.
• Move heavy batch jobs off known peaks.
• Fix slow searches and scripts, because shorter requests free slots sooner.

If the numbers point to a design problem, our integration architecture guide covers the choices that decide how much concurrency a flow needs.

Peak-readiness checklist

Run through this before your next busy period.

• Read your account limit on the Integration Governance page and write it down.
• Confirm concurrency governance is enabled in SOAP Web Services Preferences.
• List every caller, including scripts, the AI client and each Celigo connection.
• Note which applications are exempt, because they will not show in the monitor.
• Complete the worksheet for your busiest hour and add a safety margin.
• Check whether any integration has a fixed allocation, and whether it still makes sense.
• Set each connection’s concurrency so the connections and other callers together stay within the account limit or their allocation.
• Review retry logic: delays, randomness, attempt cap and duplicate safety.
• Move heavy batch jobs away from known peaks.
• Check Concurrency Monitor after the last peak for the over-limit and close-to-limit rates.
• Agree who is alerted, and what they do first, when errors appear.

Sources and method

Figures were checked against Oracle’s NetSuite help pages on 4 November 2026. Tier names, limits and license maximums can change, so confirm them in your own account. License maximums vary by contract, so confirm yours. The sizing method, symptom table and reduce-demand list are ERP Peers’ own analysis, and the scenarios are illustrative.

This guide is not endorsed by Oracle.