To ensure a fast and reliable service for everyone, the Reprtoir API limits the number of requests each account can make per minute.
Rate Limit Per Account
By default, each account can make up to 60 requests per minute.
- The limit applies to your account, not to individual API keys: all the API keys of your account share the same limit.
- The limit is shared by all the API endpoints.
- Requests are counted over a one-minute window, which starts with the first request. Once the window has elapsed, your counter is reset.
If your integration needs a higher limit, please contact us.
Rate Limit Headers
Every authenticated API response includes the following HTTP headers, so you can keep track of your current usage:
| Header | Description |
|---|---|
X-RateLimit-Limit | The maximum number of requests your account can make per minute. |
X-RateLimit-Remaining | The number of requests remaining in the current one-minute window. |
X-RateLimit-Reset | The time at which the current window resets, in UTC epoch seconds. |
Retry-After | Only on 429 responses. The number of seconds to wait before making a new request. |
Here is a sample request to try it out:
curl --include --request GET \
--url https://reprtoir.io/api/account \
--header 'X-API-Key: <Your API Key>' \
--header 'accept: application/json'
HTTP/2 200
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 59
X-RateLimit-Reset: 1792425660
...
Exceeding The Rate Limit
When your account exceeds its rate limit, the API responds with a 429 Too Many Requests HTTP status code, a Retry-After header, and the following JSON error object:
{
"error": {
"status": 429,
"code": "ERROR_RATE_LIMIT_EXCEEDED",
"documentation": "https://docs.reprtoir.com/reference/errors",
"message": "Rate limit exceeded: this account is limited to 60 requests per minute",
"details": null
}
}
Requests refused with a 429 status code are not processed: you can safely send them again once the window has been reset.
Best Practices
- Monitor the headers. Use
X-RateLimit-Remainingto slow down your requests before reaching the limit, instead of waiting for429responses. - Respect
Retry-After. When you receive a429response, wait for the number of seconds given by theRetry-Afterheader before retrying. Retrying sooner will not reset your limit any faster. - Spread your requests over time. Avoid sending large bursts of requests at once, for example by queueing them in your integration.
- Reduce the number of requests. Use the
per_pagequery parameter (up to 100) to fetch more results per request on paginated endpoints (see Pagination).
