Overview
Rate limits are enforced per API key. Different endpoint categories have different limits suited to their usage patterns.| Tier | Limit | Burst | Applies to |
|---|---|---|---|
| Read | 60 req/min | +10 | Portfolio, traders (GET), orders (GET), account |
| Write | 20 req/min | +5 | Traders (POST, PATCH, DELETE), orders (write) |
| Key create | 10 req/min | none (fixed) | POST /api/v1/keys |
| Key read | 30 req/min | +5 | GET /api/v1/keys |
Rate limit headers
Every response includes headers so you can monitor your consumption:| Header | Description |
|---|---|
X-RateLimit-Limit | Total requests allowed per minute for this endpoint tier |
X-RateLimit-Remaining | Requests remaining in the current window |
Retry-After | Seconds to wait (only present on 429 responses) |
Handling 429 responses
When you exceed a rate limit, the API returns429 Too Many Requests:
Retry-After header tells you exactly how long to wait:
Retry strategy
Implement exponential backoff with jitter rather than a fixed sleep:Tips to stay within limits
- Paginate efficiently — fetch larger pages (up to 100 records) instead of many small requests.
- Cache aggressively — portfolio summaries and trader lists don’t change every second.
- Use
since/until— filter by time range to avoid re-fetching old data. - One key per service — avoids different services competing for the same key’s budget.
- Monitor
X-RateLimit-Remaining— slow down proactively before hitting 0.