Rate limits
The /v1/ API enforces a flat rate limit of 1000 requests per minute per
credential, with a burst allowance of 50. When exceeded, the API returns
HTTP 429 with code rate_limit_exceeded and a Retry-After header (seconds).
Every credentialed /v1/ response — success or error — carries:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Sustained requests-per-minute limit for this credential. |
X-RateLimit-Remaining | Tokens remaining in the current bucket (0 on a 429). |
X-RateLimit-Reset | Unix timestamp marking the end of the current rate-limit window. |
A 429 response additionally carries Retry-After (seconds to wait before retrying).
The SDK transparently retries on 429 with backoff; the Retry-After header
is honored when present. Default config: max 3 retries with exponential
backoff (0.5s, 1s, 2s) plus jitter. Configure via Client(max_retries=...).
If you need higher per-key limits for a specific integration, reach out via support.
Simulation execution concurrency
HTTP request rate and simulation execution capacity are separate controls.
Free runs one simulation at a time; Pro runs up to five. The execution limit
is account-wide, so dashboard submissions and every API key owned by the account
share it. Additional dispatched simulations remain queued and start
automatically when a slot is released. They do not return a concurrency 429.
Service-wide overload or maintenance protection can still pause new submissions. That availability control is independent of the paid plan's unlimited usage policy and account execution queue.