Rate limits

Limits are per API key and vary by how expensive a request is. Every response - success or 429 - carries rate-limit headers, so you can pace yourself without guessing.

Limits

Each key gets its own budget in each tier. Windows are fixed and per key.

Tier	Applies to	Limit
Reads	every GET	120 / minute
Writes	creating, starting, stopping, editing, or cancelling (bots, scripts, labs, orders)	60 / minute
Trading	placing an order (POST /orders)	60 / minute
Expensive	running a backtest (POST /backtests) or starting a lab (POST /labs/{lab_id}/start)	20 / hour

Exceeding a limit answers 429 with a problem document (code: rate_limited) and a Retry-After header telling you how many seconds to wait.

Headers

We emit the IETF standard RateLimit fields, plus the widely-used X-RateLimit-* set for compatibility. Read whichever your stack understands - they describe the same window.

Standard (IETF RateLimit header fields):

Header	Example	Meaning
RateLimit-Policy	"read";q=120;w=60	the policy: q requests per w seconds
RateLimit	"read";r=118;t=54	r requests left, t seconds until the window resets

Compatibility (X-RateLimit-*, GitHub-style):

Header	Meaning
X-RateLimit-Limit	requests allowed in the window
X-RateLimit-Remaining	requests left in the window
X-RateLimit-Reset	absolute Unix time (seconds) the window resets

The two “reset” values differ by design: RateLimit’s t is seconds remaining (a countdown), while X-RateLimit-Reset is an absolute Unix timestamp. Retry-After (on a 429) matches t.

Build for it now

• Read RateLimit (or X-RateLimit-Remaining) instead of counting requests yourself.
• On 429, wait Retry-After seconds - don’t retry-storm.
• Cache what doesn’t change often: the market list moves a few times a day, not per second.
• Spread heavy jobs: backtests and lab runs share the tightest budget (20 / hour) because they run on shared capacity.