Rate Limits
Request limits and best practices for the Direct Travel API.
The Direct Travel API rate-limits each API key (or each IP in demo mode) on a 60-second sliding window. Requests over the limit return 429 with code RATE_LIMIT_EXCEEDED.
Tiers
| Tier | Rate Limit | Tracking | Description |
|---|---|---|---|
| Demo | 5 req/min | By IP | No API key required |
| Standard | 100 req/min | By API key | With valid API key |
| Custom | Contact us | By API key | Enterprise needs |
Rate limits use a sliding window (60 seconds), not fixed intervals.
Response headers
Every response carries your current rate-limit state, so you can throttle before you hit 429:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed in the current window |
X-RateLimit-Remaining | Requests left in the current window |
X-RateLimit-Reset | When the window resets, in milliseconds |
When a request is rejected, retry with exponential backoff. For error formats, refer to the API Reference — error responses (4xx/5xx) are documented under the endpoint definition.
Exemptions
These endpoints are not rate-limited:
- Static resources
- Documentation pages
FAQ
Do failed requests count? Yes. Rate limiting runs before request processing, so every request counts regardless of response status.
Do cached responses count?
Yes. Rate limiting runs as a preHandler hook before the cache is checked. Your own client-side cache does not count.
Can I have multiple API keys? Yes. Each key has its own rate limit. Useful for separating dev/staging/production.
Need higher limits? Contact your assigned account manager or reach out via the Hub chat with your expected volume and use case.