Skip to main content
API rate limiting and quotas.

Default limits

Rate limit headers

Every response includes rate limit headers:

Rate limit response

When rate limited, you’ll receive:
HTTP Status: 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. The get_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