Rate Limits

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:

HeaderDescription
X-RateLimit-LimitThe maximum number of requests your account can make per minute.
X-RateLimit-RemainingThe number of requests remaining in the current one-minute window.
X-RateLimit-ResetThe time at which the current window resets, in UTC epoch seconds.
Retry-AfterOnly 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-Remaining to slow down your requests before reaching the limit, instead of waiting for 429 responses.
  • Respect Retry-After. When you receive a 429 response, wait for the number of seconds given by the Retry-After header 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_page query parameter (up to 100) to fetch more results per request on paginated endpoints (see Pagination).