Rate Limiting
Request limits, response headers, and retry strategies.
The API enforces per-tenant rate limits to ensure fair usage and service stability.
Current limits
| Window | Limit |
|---|---|
| Per minute | 40 requests |
| Per hour | 5,000 requests |
Limits are applied per API key (per tenant). All endpoints share the same quota.
Rate limit headers
Every authenticated response includes these headers:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed per minute |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp (seconds) when the window resets |
When a rate limit is exceeded, the response also includes:
| Header | Description |
|---|---|
Retry-After | Seconds to wait before retrying |
Handling a 429 response
When you exceed the limit, the API returns:
HTTP 429
Retry-After: 42
X-RateLimit-Limit: 40
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1705312260{
"success": false,
"requestId": "...",
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Rate limit exceeded. Please retry after 42 seconds."
}
}Recommended retry strategy
- Read the
Retry-Afterheader value. - Wait for the specified number of seconds.
- Retry the request.
For automated integrations, implement exponential backoff as a fallback:
wait = min(2^attempt * 1 second, 60 seconds)
Tips
- Batch your work — run simulations sequentially rather than in parallel bursts.
- Cache results — simulation results don't change. Store the
simulationIdand retrieve results withGET /simulations/{simulationId}/pdfinstead of re-running the simulation. - Monitor the headers — check
X-RateLimit-Remainingproactively to avoid hitting the limit.
Updated about 1 month ago