Rate limits
Limits keep the platform fast for everyone. They apply per API user, across both the REST API and the MCP server.
Limits at a glance
| Limit | Value | When exceeded |
|---|---|---|
| Request rate | 60 requests per rolling 60 seconds | Immediate 429 with a Retry-After header |
| Concurrency | 1 request in progress at a time | Extra requests wait in line (first in, first out) |
| Queue | Up to 10 waiting requests | 429 once the queue is full |
- Rolling window. The 60-second window advances in 10-second steps, so capacity frees up gradually rather than all at once.
- Sequential processing. Your requests run one at a time. Sending requests in parallel does not make an integration faster. It only fills the queue. Send them sequentially.
- Token requests to
POST /Auth/Tokenare not rate limited, but cache tokens for their full lifetime anyway.
The 429 response
Retry-After is the number of whole seconds to wait. It is present when the request-rate limit is hit. When the queue is full it may be absent, so fall back to exponential backoff.
Handling limits
Best practices
- Pull data on a schedule (for example nightly after month-end positions are final) rather than on every page view in your application.
- On REST, prefer one request with
id=0orhistoricalMonthsover many small requests, as long as response times stay acceptable. - Use the Transaction log for incremental syncs instead of re-downloading full periods.