API reference

Rate limits

The per-key budgets, the headers that report them, and how to back off.

Limits are per API key and generous — a dashboard polling every account it owns should never notice them. They exist to stop one integration from crowding out live trading, which shares the same database.

Bucket	Methods	Budget
Reads	`GET`	1,200 requests / minute
Writes	`POST` `PUT` `PATCH` `DELETE`	120 requests / minute

The same for every plan tier. Your tier decides how many accounts you can run, not how fast you may ask about them.

Headers

Every response carries your current position:

Response headers

X-RateLimit-Limit: 1200
X-RateLimit-Remaining: 1187
X-RateLimit-Reset: 42

X-RateLimit-Limitinteger

The budget for this bucket.

X-RateLimit-Remaininginteger

Requests left in the current window.

X-RateLimit-Resetinteger

Seconds until the window resets and the budget refills.

Going over

429 Too Many Requests

{
  "error": {
    "code": "rate_limited",
    "message": "too many requests — retry in 42s"
  }
}

A 429 also carries Retry-After in seconds. Wait that long rather than retrying immediately; a tight retry loop spends the next window before it opens.

Staying well under

Read one account’s analytics object rather than assembling the same picture from several calls — it is one request for the whole thing. And for breaches and passes, prefer being told over asking: polling 1,250 accounts on a timer spends most of your budget learning that nothing happened.

PreviousPagination NextIdempotency