All API requests are subject to rate limiting to ensure platform stability and fair usage across all customers.
General Rate Limit
By default, all requests are throttled to 1,000 requests per 5 minutes per API token (or per IP address for unauthenticated requests). Once the limit is exceeded, subsequent requests will receive a 429 Too Many Requests response until the window resets.
| Limit | Window | Scope |
|---|---|---|
| 1,000 requests | 5 minutes | API token or IP address |
Response Headers
Every API response includes rate limit headers so you can track your usage proactively:
| Header | Description | Example |
|---|---|---|
X-RateLimit-Limit | Maximum number of requests allowed in the current window | 1000 |
X-RateLimit-Remaining | Number of requests remaining in the current window | 999 |
X-RateLimit-Reset | Unix epoch timestamp (in seconds) when the current window resets | 1774476900 |
When the limit is exceeded, the response will also include:
- HTTP Status:
429 Too Many Requests - Retry-After: Number of seconds until the throttle window resets
Best Practices
- Respect the
Retry-Afterheader — when present on a429response, wait the specified duration before retrying. This is the most reliable way to know when requests will be accepted again. - Fall back to exponential backoff with jitter — if
Retry-Afteris not present, use exponential backoff (e.g., 1s, 2s, 4s, 8s) with random jitter to avoid thundering herd retries. - Set a max retry count — cap retries (e.g., 3–5 attempts) to avoid indefinite retry loops.
- Spread requests evenly — distribute requests over time rather than sending in bursts to stay under the limit proactively.
Safelisting
If you run automated test suites or CI/CD pipelines against the API and encounter rate limiting, contact support to discuss safelisting options.