Rate Limits
BillerAPI enforces rate limits to ensure fair usage and platform stability. All limits apply per client, per environment.
Default Limits
| Endpoint Type | Limit | Window |
|---|---|---|
| Most endpoints (POST, PUT, DELETE) | 100 requests | Per minute |
| Read-only endpoints (GET) | 1,000 requests | Per minute |
These limits are the same in sandbox and production. If you need higher limits, contact us at support@billerapi.com.
Rate Limit Headers
When you exceed a rate limit, the API returns a 429 Too Many Requests response with a Retry-After header indicating how many seconds to wait before retrying.
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json
{
"status_code": 429,
"error": "rate_limit_exceeded",
"message": "Rate limit exceeded. Retry after 30 seconds.",
"documentation_url": "https://docs.billerapi.com/concepts/rate-limits"
}
Backoff Strategy
Use exponential backoff with jitter when retrying rate-limited requests. Always respect the Retry-After header when present.
Exponential backoff with Retry-After
async function fetchWithRetry(url, options, maxRetries = 3) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
const response = await fetch(url, options);
if (response.status !== 429) {
return response;
}
if (attempt === maxRetries) {
throw new Error('Max retries exceeded');
}
// Respect Retry-After header, or use exponential backoff
const retryAfter = response.headers.get('Retry-After');
const delay = retryAfter
? parseInt(retryAfter, 10) * 1000
: Math.min(1000 * Math.pow(2, attempt), 30000);
// Add jitter to prevent thundering herd
const jitter = Math.random() * 1000;
await new Promise(resolve => setTimeout(resolve, delay + jitter));
}
}Best Practices
- 1.Cache responses — biller metadata and account details change infrequently. Cache GET responses to reduce request volume.
- 2.Use webhooks instead of polling — subscribe to events like
bill.createdinstead of polling for new bills. - 3.Batch where possible — fetch multiple bills in a single paginated request instead of one-by-one.
- 4.Implement backoff — never retry immediately after a 429. Always wait at least the
Retry-Afterduration.
Related
- Error Handling — error response format and codes
- Authentication — API key and bearer token auth
- Webhooks — event-driven alternative to polling