Default limits
Rate limit headers
Every response includes rate limit headers:Rate limit response
When rate limited, you’ll receive:429 Too Many Requests
Best practices
1. Implement exponential backoff
2. Use batch endpoints
Instead of individual requests:3. Cache results
Per-endpoint limits
Some endpoints have specific limits:Thread-safe in-memory limiter
The default in-memory rate limiter is thread-safe. All check-and-record operations (per-key and global) are protected by a lock, making it safe to use with multi-threaded ASGI servers such as Uvicorn with multiple workers. Theget_reset_time method also operates under the lock to prevent stale reads.
Fail-closed enforcement
When using Redis-backed rate limiting, the rate limiter operates with a fail-closed policy. If the Redis backend encounters an error at runtime, requests are denied rather than allowed through. This ensures that a temporary Redis outage does not silently bypass rate limits. If Redis is unavailable at startup, an in-memory fallback is used until the service is restarted with a healthy Redis connection.Enterprise options
For higher limits, contact us for:- Custom rate limits
- Dedicated infrastructure
- SLA guarantees