Rate Limits
Understand global and daily rate limits, response headers, and recommended retry practices.
Rate Limit Overview
Rate limits keep API usage stable and fair across all integrations. The current global rate limit is 120 requests per 60 seconds across all endpoints.
Handling Rate Limits
When you exceed our rate limit, requests will be blocked until the next minute window begins. The API returns a 429 Too Many Requests status code in these cases.
Response Headers
You can monitor your current rate limit status using the following response headers:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum number of requests allowed per minute. |
X-RateLimit-Remaining | Number of requests remaining in the current window. |
X-RateLimit-Reset | Unix timestamp when the rate limit resets. |
For example:
response = requests.post(url, headers=headers)
print(response.headers)
>>> {'Date': 'Mon, 03 Mar 2025 21:20:33 GMT',
'Content-Type': 'application/json',
'Content-Length': '106',
'Connection': 'keep-alive',
'x-ratelimit-limit': '120',
'x-ratelimit-remaining': '119',
'x-ratelimit-reset': '1741036893',
'x-request-id': 'da1b77ba-6cec-433b-a0dc-e7ad55d8a28d',
'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'}In this case, the X-RateLimit-Remaining header tells you that you have 119 requests left before hitting the limit.
Convert the X-RateLimit-Reset Unix timestamp to determine when requests can resume. For example, 1741036893 corresponds to March 3, 2025, 21:21:33 GMT.
Verification Retry Policy
There is no daily limit on verification attempts per identifier. Clients may submit multiple verification requests for the same identifier as needed.
Because each verification is processed independently and counts toward billing, clients are responsible for controlling their retry behavior and avoiding unnecessary duplicate verifications.
We recommend implementing a client-side deduplication strategy:
Use last_updated_at to determine whether a recent verification already exists before creating a new one.
Apply a backoff strategy between retry attempts instead of retrying immediately.
Do not treat can_retry=true as a signal to immediately submit another verification. It only indicates that the verification may be attempted again.
This approach helps prevent duplicate requests and gives clients direct control over retry frequency and associated costs.
Recommended Practices
To work effectively with rate limits when using the Buró de Ingresos API:
- Gracefully handle
429status codes by retrying after the reset time. - Space out your requests evenly throughout the time window.
- Avoid tight loops and unnecessary bulk requests that can exhaust your limit.
- Use Webhooks instead of polling whenever possible.
Updated 4 days ago
