Rate Limits
The Atrium API enforces rate limits to ensure fair usage and protect system stability.
Default limits
| Scope | Limit | Window |
|---|---|---|
| Per user | 100 requests | Per minute |
| Per tenant | 1,000 requests | Per minute |
| Login endpoint | 10 attempts | Per minute per IP |
These are the default limits. Self-hosted deployments can adjust rate limits in the server configuration.
Rate limit headers
Every API response includes rate limit information in the 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 window resets. |
Handling 429 responses
When you exceed the rate limit, the API returns:
HTTP/1.1 429 Too Many Requests
Retry-After: 30
{
"error": "rate_limit_exceeded",
"message": "Rate limit exceeded. Try again in 30 seconds."
}
The Retry-After header tells you how many seconds to wait before retrying. Implement exponential backoff in your client code.
Best practices
- Cache responses where possible. Visitor profiles and site configurations change infrequently.
- Batch operations instead of making individual requests. Use list endpoints with filters rather than fetching records one by one.
- Respect Retry-After. Continuing to send requests after a 429 response may result in longer backoff periods.
- Use webhooks for event-driven integrations instead of polling. The webhook adapter sends events to your endpoint as they happen, without consuming your rate limit.