Rate Limits

To protect platform stability and ensure fair access for all clients, the API limits how many requests you can make per minute. This guide explains how requests are counted, how to read the rate limit headers included on every response, and how to handle requests that are rejected with a 429 status.

How Rate Limiting Works

Rate limits are applied per user. All requests made with your credentials draw from the same quota, no matter which API key or account they use. Creating additional API keys does not increase your limit.

Each request counts against exactly one of three categories, so heavy read traffic never blocks your ability to submit orders:

Category	Applies to	Default limit
Read	All GET requests, such as orders, positions, balances, and instruments	1,000 requests / minute
Write	All POST, PUT, PATCH, and DELETE requests, such as order entry, cancels, and replaces	1,000 requests / minute
Omni AI	Omni AI and MCP endpoints, regardless of method	1,000 requests / minute

Quotas refill continuously rather than resetting at the top of each minute. At 1,000 requests per minute, one request’s worth of capacity is restored every 60 ms. You can burst up to your full remaining quota at any moment, but sustained throughput cannot exceed the per-minute limit.

Default limits may be adjusted over time; treat the rate limit headers below, not the numbers in this table, as the source of truth for your current limits.

Rate Limit Headers

Every response from a rate-limited endpoint includes headers describing where you stand:

Header	Meaning
x-ratelimit-limit	Your per-minute limit for the request’s category.
x-ratelimit-remaining	Requests you can still make right now in that category.
x-ratelimit-reset	Seconds until your quota is fully restored. This is a relative duration, not a timestamp.

HTTP/1.1 200 OK
x-ratelimit-limit: 1000
x-ratelimit-remaining: 743
x-ratelimit-reset: 16

Because x-ratelimit-reset reports when the quota is fully restored, you rarely need to wait that long. Capacity refills continuously, so individual requests become available much sooner.

Handling 429 Responses

When you exceed a limit, the request is rejected with HTTP 429 and the standard error envelope:

{
  "error": {
    "code": 429,
    "message": "Too Many Requests"
  },
  "metadata": {
    "request_id": "523be14bfc539676885a2ef4629e5322"
  }
}

The response also includes a retry-after header with the number of seconds to wait before the next request will be accepted:

HTTP/1.1 429 Too Many Requests
x-ratelimit-limit: 1000
x-ratelimit-remaining: 0
x-ratelimit-reset: 60
retry-after: 1

A 429 means the request was never processed. An order submission rejected this way never reached the trading engine, so it is always safe to retry after waiting.

In rare cases a 429 can originate from an internal service and omit the rate limit headers. If retry-after is absent, fall back to exponential backoff.

Best Practices

• Respect retry-after. When you receive a 429, wait at least the indicated number of seconds before retrying. Retrying sooner will only be rejected again.
• Back off with jitter. If consecutive retries keep failing, increase the wait exponentially and add random jitter so that parallel workers don’t retry in lockstep.
• Watch x-ratelimit-remaining. Smooth your request rate before you hit the limit instead of reacting to 429s. If remaining is trending toward zero, slow down.
• Fetch efficiently. Avoid tight polling loops. Use pagination and range filters to retrieve only what changed, in as few requests as possible. For example, poll with updated_at.gte set to the time of your previous poll.
• Don’t shard across API keys. All of your keys share one quota, so spreading traffic across keys does not raise your effective limit.