# Rate Limits

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.

## Response Headers

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.

## Limits by Endpoint Group

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 |


## Best Practices

- **Monitor response headers** to track your remaining budget and avoid hitting limits.
- **Implement exponential backoff** when you receive a `429` response. Use the `Retry-After` header 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.