Guide

Rate limits

Limits are per account, shared by all of its keys and projects. There are no credits, no monthly quota and no per-endpoint prices: only these rates.

On this page

The limits
Rate-limit headers
When a limit is exceeded
Concurrency
Other protections

The limits#

Every /v1 request, every MCP request and every WebSocket upgrade counts.

Limit	Value	Window
Requests per minute	250	Rolling 60 seconds
Requests per second (burst)	30	Rolling second
Requests in flight	4	Being processed at once

The limits are the same on every plan. GET /v1/account always reports the values in force, because they may be adjusted per deployment.

Rate-limit headers#

Every authenticated response carries:

Header	Value
`X-RateLimit-Limit`	Requests allowed per minute (250).
`X-RateLimit-Remaining`	Requests left in the current minute window.
`X-RateLimit-Reset`	Unix milliseconds when one more request is allowed in the minute window.
`X-RateLimit-Burst-Limit`	Requests allowed per second (30).
`X-RateLimit-Burst-Remaining`	Requests left in the current one-second window.

/v1/account/limits returns the same values without spending a data call, together with the live state of your windows.

Inspect the headers

curl -sS -D - -o /dev/null "https://api.ordermap.si/v1/account/limits" \
  -H "Authorization: Bearer $ORDERMAP_API_KEY" | grep -i '^x-ratelimit'

When a limit is exceeded#

The response is 429 with code rate_limited (minute window) or burst_limited (second window), a Retry-After header in whole seconds and retry_after_ms in the body. Rejected requests do not consume the window, but sustained hammering after 429 responses triggers a temporary cooldown.

Read Retry-After and wait that long before the next request.
Send requests from a small pool of workers, not an unbounded burst.
Back off exponentially with jitter when Retry-After is absent. A ready-made helper is in Errors.

Concurrency#

An account may have at most 4 requests being processed at once (the default). A fifth simultaneous request is answered 429 rate_limited with Retry-After: 1. The service as a whole also has a bounded work capacity: when it is full a request is answered 503 upstream_busy. Retry with backoff.

Other protections#

Requests without a key (/v1/status, /v1/openapi.json, and missing or malformed credentials) share a separate budget per client network (by default 60 per minute) and answer 429 rate_limited when it is spent.
Every endpoint answers within 20 seconds or returns 504 upstream_timeout.
Heavy historical reads of retained data are admitted a few at a time and can answer 503 upstream_busy. Retry shortly.
WebSockets have their own limits: one connection per stream, message sizes and symbol counts (see WebSockets). Opening more than about 20 WebSocket connections in ten minutes causes a ten-minute cooldown.
Behaviour that looks like key sharing across many networks, scraping with mostly failing requests, or running several accounts from one network is flagged and can lead to a cooldown (429 cooldown) or suspension (403 account_suspended).

Limits are enforced per API process.