Rate limiting

The public API enforces a limit of 600 requests per minute per API key, in a fixed window: the counter resets at the start of each minute. The limit applies to all methods combined.

Response headers

Every authenticated response reports the state of your current window:

Header	Example	Description
X-RateLimit-Limit	600	Request limit for the window.
X-RateLimit-Remaining	597	Requests left in the current window.
X-RateLimit-Reset	1753272060	Unix time (seconds) when the window resets.
Retry-After	27	Only on 429: seconds until you can retry.

Response when exceeded

When you go over the limit, the API responds 429 Too Many Requests with the standard error envelope:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1753272060
Retry-After: 27

{
  "message": "Limite de requisições excedido",
  "code": "RATE_LIMITED"
}

Wait the seconds indicated in Retry-After (or until the instant in X-RateLimit-Reset) before the next request. Since the window is fixed, retrying earlier just wastes calls — the response stays 429 until the minute rolls over.

Best practices

• Watch X-RateLimit-Remaining and slow down before hitting zero, instead of reacting to the 429.
• Retry with backoff honoring Retry-After — never in a tight loop.
• Use X-Idempotency-Key on mutations: the post-429 retry is safe and doesn't duplicate the operation.
• Prefer list filters and per_page=100 over page-by-page sweeps — fewer requests, same information (Pagination and filters).
• Spread batch workloads (imports, syncs) over time instead of bursting at the top of the minute.