Rate Limiting
The Bitcompare API enforces per-endpoint rate limits to ensure fair usage.
Default limits
Rate limits depend on whether you include an API key with your requests.
| Tier | Limit | Scope |
|---|---|---|
| Free (no API key) | 60 req/min | Per IP address |
| Authenticated (API key) | 1,000 req/min | Per API key |
| Chart endpoints | 30 req/min | Both tiers |
Rate-limit headers
Every response includes standard rate-limit headers so you can monitor your usage:
Rate-limit response headers
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 2026-02-25T12:05:00.000Z
Retry-After: 12
- Name
X-RateLimit-Limit- Type
- integer
- Description
The maximum number of requests allowed in the current window.
- Name
X-RateLimit-Remaining- Type
- integer
- Description
The number of requests remaining in the current window.
- Name
X-RateLimit-Reset- Type
- string
- Description
ISO 8601 timestamp when the current window resets.
- Name
Retry-After- Type
- integer
- Description
Number of seconds to wait before retrying (only present on
429responses).
Handling 429 responses
When you exceed the limit, the API returns a 429 Too Many Requests status. Implement exponential backoff or respect the Retry-After header.
429 response body
{
"error": {
"message": "Too many requests, please try again later",
"code": "RATE_LIMIT_EXCEEDED"
},
"retryAfter": 12
}
The retryAfter field in the response body mirrors the Retry-After header value (in seconds).
Best practices
- Cache responses — prices and rates update every few seconds; there's no need to poll more frequently.
- Use WebSockets — for real-time price data, connect to the WebSocket endpoint instead of polling.
- Batch requests — the symbol resolution endpoint supports batch resolution of up to 100 symbols in a single request.
- Respect headers — check
X-RateLimit-Remainingbefore making additional requests.