Rate limits

Each API key can send 600 requests per minute by default. Over that, requests get 429 until the minute is up.

How the limit works

• Per key. Every key has its own limit, shown on the API keys page.
• Per request, not per question. A /v1/systemone request with 32 questions counts once. Every authenticated request counts, including GET /v1/models and GET /v1/templates.
• Fixed one-minute window. The window opens with the first request and resets 60 seconds later.
• Invalid keys don't count. Requests rejected with 401 are not counted against any key.

Responses don't include remaining-quota headers. Pace your client to stay under the limit and handle 429 when it happens.

If you need a higher limit, contact support: limits can be raised per key.

When you hit the limit

You get 429 with error_type rate_limit_error. The retry-after header says how many seconds remain until the window resets:

HTTP/1.1 429 Too Many Requests
content-type: application/json
retry-after: 38
x-request-id: req_0t9rn7vlp9c6tl5rgaeetoc8
x-typesafe-request-id: req_0t9rn7vlp9c6tl5rgaeetoc8

{
  "detail": {
    "error_type": "rate_limit_error",
    "message": "Rate limit of 600 requests per minute exceeded."
  }
}

Wait that long, then retry. Rate-limited requests are not billed. The Jev SDKs retry 429 automatically and honour retry-after.

Capacity errors

The rate limit is separate from capacity. When the service is busy, a request within your limit can still get 529 overloaded_error, or 503 api_error if the backend is briefly unavailable. Both are temporary: retry after a short delay with backoff. See Errors.

Staying under the limit

• Batch questions. If you ask several things about the same text, send them as up to 32 questions in one /v1/systemone request. At 600 requests per minute, that allows up to 19,200 decisions per minute per key. Billing is still per question.
• Cap concurrency. Run requests through a small worker pool instead of starting them all at once. See the batch example in Code examples.
• Separate workloads. Give batch jobs their own key so a backfill cannot use up the limit of your production traffic.
• Retry politely. On 429, wait for retry-after. Retrying immediately only fails again.