Rate Limits
Rate limits protect the platform from abuse and ensure fair access for all users. Limits are enforced per-IP for unauthenticated requests and per-API-key for authenticated requests.
API Key Tiers
Each API key is assigned a rate limit tier that governs the overall request throughput:
| Tier | Limit | Description |
|---|
standard | 10 req/s | Default for new keys |
premium | 50 req/s | Premium integrations |
market_maker | 100 req/s | High-frequency market makers |
Administrators can also set per-key custom overrides via the rate_limit_override field. Custom overrides take precedence over the tier default. The override is a JSON object:
{ "requests": 200, "window_seconds": 1 }
Per-Endpoint Limits
Independent of your API key tier, individual endpoints have their own rate limits. The more restrictive of the two (tier vs. endpoint) applies.
Public Endpoints
| Method | Endpoint | Limit | Window |
|---|
| GET | /v1/markets | 100 req | 1 min |
| GET | /v1/markets/:id | 200 req | 1 min |
| All | All other unlisted endpoints | 100 req | 1 min |
Authentication Endpoints
| Method | Endpoint | Limit | Window |
|---|
| POST | /v1/auth/privy | 10 req | 1 min |
| POST | /v1/auth/callback | 10 req | 1 min |
| GET | /v1/auth/oauth/:provider | 10 req | 1 min |
| POST | /v1/auth/refresh | 5 req | 1 min |
| POST | /v1/auth/revoke | 10 req | 1 min |
| POST | /v1/auth/revoke-all | 5 req | 1 min |
| GET | /v1/wallets/link/nonce | 10 req | 1 min |
| POST | /v1/wallets/link | 10 req | 1 min |
Fiat Endpoints
| Method | Endpoint | Limit | Window |
|---|
| POST | /v1/user/fiat/offramp/sessions | 5 req | 1 min |
| POST | /v1/user/fiat/onramp/sessions | 10 req | 1 min |
| POST | /v1/user/fiat/onramp/sessions/:id/complete | 20 req | 1 min |
Trading Endpoints
| Method | Endpoint | Limit | Window |
|---|
| POST | /v1/orders | 10 req | 1 sec |
| DELETE | /v1/orders/:hash | 20 req | 1 sec |
| GET | /v1/orders/:hash | 20 req | 1 sec |
Batch Trading Endpoints
| Method | Endpoint | Limit | Window |
|---|
| POST | /v1/orders/batch | 5 req | 1 sec |
| DELETE | /v1/orders/batch | 5 req | 1 sec |
| DELETE | /v1/orders/cancel-all | 2 req | 1 sec |
| DELETE | /v1/orders/cancel-market | 2 req | 1 sec |
| POST | /v1/orders/heartbeat | 1 req | 1 sec |
Deployment Endpoints
| Method | Endpoint | Limit | Window |
|---|
| POST | /v1/markets/:id/deploy | 5 req | 1 min |
Admin Endpoints
| Method | Endpoint | Limit | Window |
|---|
| POST | /admin/markets | 10 req | 1 min |
| POST | /admin/markets/:id/resolve | 5 req | 1 min |
Every response includes rate limit information:
| Header | Description |
|---|
X-RateLimit-Limit | Maximum requests per window |
X-RateLimit-Remaining | Requests remaining in current window |
X-RateLimit-Reset | Unix timestamp when window resets |
Exceeded Limits
When you exceed your rate limit, the API returns 429 Too Many Requests:
{
"error": "rate limit exceeded"
}
Back off and retry after the X-RateLimit-Reset timestamp.
Best Practices
- Use batch endpoints to reduce request count (up to 15 orders per batch — see
/api/v1/batch-operations)
- Cache market data locally and use WebSocket for real-time updates
- Monitor headers — check
X-RateLimit-Remaining to avoid hitting limits
- Use cancel-all instead of individual cancels when unwinding positions
- Upgrade your tier — contact support if you need higher limits
- Use heartbeat wisely — the 1 req/s heartbeat limit is intentional; send exactly one per second