NetSuite enforces API concurrency and rate limits that are well-documented but frequently underestimated when moving from development to production. The limit that causes no issues with 50 test orders becomes the primary failure mode when 500 orders arrive during a peak sales event.
What the Limits Actually Are
NetSuite’s REST API concurrency limit is governed per account, not per integration. If your integration, a NetSuite employee running a saved search, and an automated report all hit the API simultaneously, they share the same concurrency budget. The limits are not published as fixed numbers because they vary by account tier and Oracle adjusts them, but the practical ceiling most integrations encounter is in the range of 10–15 concurrent REST requests before throttling begins.
SOAP-based web services have separate (and generally more generous) concurrency limits, which is one reason legacy integrations stayed on SOAP longer than REST advocates expected.
The Queue-Based Pattern
The approach that holds up at volume is queue-based consumption with explicit concurrency control. Orders from WooCommerce or Shopify enter a queue. A worker pool of fixed size (sized to stay within NetSuite’s concurrency limit with headroom) pulls from the queue and makes API calls. The queue absorbs spikes; the worker pool rate-limits the actual API traffic.
The worker pool size needs to account for other API consumers in the same NetSuite account. Setting your worker pool to 10 concurrent requests assumes nothing else is hitting the API. In practice, something always is. A safe starting point is workers set to 5, with monitoring to detect throttling errors and alerting to surface when the queue depth grows faster than it drains.
Retry Logic That Does Not Make Throttling Worse
Naive retry logic — catch a 429, wait 1 second, retry — makes throttling worse under load. If 10 workers all hit a 429 and retry after 1 second, they all collide again. Exponential backoff with jitter is the standard: the retry delay doubles with each attempt, plus a random fraction to spread retries across time.
Separate the retry budget by error type. A 429 (rate limit) warrants aggressive retry with backoff. A 400 (bad request) should not be retried automatically — the record is malformed and retrying wastes the concurrency budget. A 503 (service unavailable) should retry with a longer initial delay than a 429, because it often indicates a NetSuite maintenance window rather than a transient spike.
Bulk Operations Where Available
NetSuite’s SuiteAnalytics Connect (JDBC/ODBC) and CSV import capabilities do not count against REST API concurrency limits. For data flows that are batch by nature — end-of-day inventory reconciliation, weekly price updates — these mechanisms are often more appropriate than REST calls for each record. The integration architecture should match the mechanism to the use case: REST for real-time transactional sync, bulk import for large periodic updates.