Reference
Rate limits
Finora Business enforces three time-window limits per API key. Every response carries headers that tell you exactly where you stand.
Limits
| Window | Requests | Notes |
|---|---|---|
| Per minute | 60 | Rolling window. |
| Per hour | 1,000 | Aligned to the clock hour. |
| Per day | 10,000 | Resets at UTC midnight. |
| Burst | 10 concurrent | Short spikes throttled at 10 in flight. |
Limits apply per API key. Running multiple keys (one per integration) gives you independent budgets. Enterprise customers negotiate higher limits — contact sales.
Response headers
Every response — successful or not — includes rate-limit headers and the same numbers in the meta.rateLimit block.
X-RateLimit-Limit: 60 X-RateLimit-Remaining: 57 X-RateLimit-Reset: 2026-04-17T10:31:00Z
When you hit the limit
Over-quota requests return HTTP 429 with a retryAfter hint in seconds.
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
{
"success": false,
"error": {
"code": "RATE_LIMIT",
"message": "Rate limit exceeded. Retry after 45 seconds.",
"retryAfter": 45,
"requestId": "req_a1b2c3d4e5f6g7h8"
}
}Retry strategy we recommend
Honour
retryAfterSleep at least that many seconds before retrying. Don't retry sooner, even if the window ticks over.
Add jitter on retry
If several workers all hit 429 at the same moment, they will all come back in sync without jitter. Spread the retry by ±20%.
Cap concurrency at 10
Match the burst limit. A queue that lets 10 requests run at once and holds the rest absorbs traffic spikes gracefully.
Don't retry 4xx (except 429)
A 400, 401, or 403 won't change on retry — fix the request instead. 429 and 500 are the two worth retrying.