Rate limits

Overview

To keep the platform stable and fair for everyone, the Business NXT API applies rate limiting. There are two independent limits, checked in this order, and a request must satisfy both to be processed.

There are two independent limits, and a request must satisfy both to be processed.

1. Per-token request rate limit

Checked first, at the gateway - before the request reaches the application. It enforces a request-rate limit keyed on the Authorization token (i.e. per authenticated user/application):

Exceeding this limit returns HTTP 429 Too Many Requests from the gateway. Keep your per-token request rate under 600/minute and spread bursts out over time.

2. Concurrent (outstanding) request limit

This caps how many of your requests may be in progress at the same time (per company/customer). A request occupies a slot from the moment it is accepted until it completes. This protects the backend from being overwhelmed by many simultaneous long-running calls.

A slot is released as soon as its request finishes. If a request never completes normally (for example, your client disconnects or times out), its slot is automatically freed after 30 minutes so it cannot block future requests indefinitely.

This limit is applied per company or per customer, and the two scopes are counted independently: a request made in a company context does not count toward the customer total, and vice versa. Activity from one company (or customer) never consumes another’s allowance.

When exceeded, the request is rejected and surfaced as a GraphQL error in the errors array:

{
  "errors": [
    {
      "message": "Company 12345 has 60 requests in progress. Limit is 60.",
      "extensions": {
        "code": "OUTSTANDING_LIMIT_EXCEEDED",
        "limit": 60
      }
    }
  ]
}

For a customer-scoped request the message begins “Customer 12345 has …”.

There is no fixed retry time for this limit - a slot frees up only when one of your in-flight requests completes. Retry with a short exponential back-off rather than waiting a fixed interval.

Integrator guidance

• Handle both rejection formats. The per-token limit returns a plain HTTP 429 from the gateway; the concurrent limit returns an HTTP 200 with a GraphQL error carrying extensions.code = "OUTSTANDING_LIMIT_EXCEEDED".
• For the per-token rate limit, keep your request rate under 600/minute per Authorization token and spread out bursts.
• For the concurrent request limit, there is no fixed wait: back off and retry once your in-flight requests have had time to complete. Use exponential back-off with jitter.
• The per-token rate limit is per Authorization token, while the concurrent limit is per company/customer and counted independently. Parallelizing work across different companies or customers does not draw from a single shared concurrent-request quota.