Rate Limits
Request limits per endpoint and handling 429 errors
The API enforces rate limits to ensure fair usage and system stability. Limits are applied per API key using a sliding window algorithm.
Rate Limit Tiers
| Tier | Limit | Endpoints |
|---|---|---|
| catalog | 120 req/min | Settings, locations, cars, categories, addons, features |
| quote | 30 req/min | Single quotes, availability check |
| bulk_quote | 10 req/min | Bulk quotes |
| session | 20 req/min | Session CRUD, addon updates |
| coupon | 10 req/min | Coupon validation |
| booking | 5 req/min | Create booking, cancel, send message |
| booking_lookup | 10 req/min | Get booking by reference |
Rate Limit Headers
Every API response includes rate limit information:
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 115
X-RateLimit-Reset: 1715263200000| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp (ms) when the window resets |
Handling 429 Too Many Requests
When you exceed the rate limit, you'll receive a 429 response:
{
"error": "Rate limit exceeded"
}The response includes a Retry-After header with the number of seconds to wait:
Retry-After: 45Best Practices
- Respect
Retry-After— Wait the specified time before retrying - Use bulk endpoints — Use
POST /quotes/bulkinstead of multiplePOST /quotescalls - Cache catalog data — Settings, locations, and cars change infrequently; cache them client-side
- Implement exponential backoff — If retries continue to fail, increase the wait time