The Customer API enforces rate limits to protect service stability and ensure fair usage across all integrators. Limits are applied per user (identified by OAuth client and user ID) unless otherwise noted.
Every response includes rate limit headers:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the current window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp when the current window resets |
When a rate limit is exceeded, the API returns a 429 Too Many Requests response with a Retry-After header indicating the number of seconds to wait before retrying.
Rate limits for authenticated endpoints are scoped to the combination of your OAuth client_id and the authenticated user_id. Each user of your integration has their own independent rate limit budget. Unauthenticated endpoints (authentication flows) are rate limited by client IP address.
| Endpoint Group | Limit |
|---|---|
| Authentication (login, logout, authorize, signup, token) | 300/min |
| Agreements | 300/min |
| Counterparties | 300/min |
| Customer | 300/min |
| Notifications | 300/min |
| Pockets | 120/min |
| Portals | 300/min |
| Reports | 300/min |
| Subscriptions | 300/min |
| Team | 300/min |
| Trades | 120/min |
| Trading Strategies | 300/min |
| Transactions | 120/min |
| Transfer Requests (read) | 120/min |
| Transfer Requests (create) | 60/min, 1/sec |
| User | 300/min |
- Monitor response headers to track your remaining budget and avoid hitting limits.
- Implement exponential backoff when you receive a
429response. Use theRetry-Afterheader to determine the minimum wait time. - Spread requests over time rather than sending bursts. Bursting can exhaust your per-minute budget quickly even if your average request rate is well within limits.