Skip to content

Rate limits

Requests are limited in two dimensions at once: per credential and per firm. A request is served only if both have room, so one busy integration cannot starve the rest of your firm, and your firm cannot be starved by anyone else's.

Plan tiers

Your administrator sets a plan on each credential. New credentials start on Sandbox.

Plan Sustained requests per second, per credential
Sandbox 5
Standard 50
Pro 200

The per-firm allowance is four times the per-credential rate unless your agreement sets it otherwise, so several credentials on the same plan can run concurrently without immediately colliding.

Both dimensions allow roughly a second of unused allowance to accumulate, so a short burst above the sustained rate is fine as long as the average holds.

Individual credentials can be given their own limits in place of the plan default. If your integration has an unusual shape — a nightly reconciliation that wants a high ceiling for twenty minutes and nothing the rest of the day — ask rather than working around the limit with more credentials.

Writes are metered exactly like reads — there is no separate write budget. A bulk account create counts as one request however many rows it carries, which is the reason to prefer it over a loop of single creates.

The token endpoint has its own limit

POST /api/v1/oauth/token is limited separately, to 10 requests per minute per client_id, and that budget is not shared with your data traffic. It is sized for a service that caches its token, not for one that mints per request. See caching and refresh.

What a limited response looks like

A limited request is refused, never queued:

HTTP/1.1 429 Too Many Requests
Retry-After: 1
X-RateLimit-Limit: 50
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1
Content-Type: application/problem+json

{
  "type": "https://docs.sirix.ai/errors/rate_limited",
  "title": "Too Many Requests",
  "status": 429,
  "code": "rate_limited",
  "detail": "rate limit exceeded",
  "request_id": "01J0000000000000000000000",
  "errors": []
}
Header Meaning
Retry-After Seconds to wait before retrying.
X-RateLimit-Limit The per-second allowance in force for this credential.
X-RateLimit-Remaining How much of it is left — 0 on a refusal.
X-RateLimit-Reset Seconds until allowance is available again.

The headers appear on the refusal

These headers are sent with a 429. Successful responses do not carry them, so you cannot use them to watch how close you are getting. Pace your client from your own request rate and treat the 429 as the backstop, not the signal.

The rate_limited code is marked safe to retry: the request never started, so replaying it is correct. Honor Retry-After rather than retrying immediately, and add jitter if many workers can be limited at the same moment. The SDKs do both.

Notes for delegated tokens

A delegated token is metered against the credential that minted it, at the Sandbox rate rather than that credential's plan. A trader session is a handful of requests plus a WebSocket, so this is generous in practice — but do not use delegated tokens to drive bulk work.