Rate Limiting
Understand Cencori's rate limiting system, how to handle limits, and best practices for high-volume applications.
What is Rate Limiting?
Rate limiting controls how many requests you can make in a given time period. This protects the platform from abuse and ensures fair usage for all users.
Cencori enforces rate limits at multiple levels: per project, per user, and per organization.
Default Rate Limits
| Tier | Requests/Minute | Requests/Day | Burst Limit |
|---|---|---|---|
| Free | 10 | 1,000 | 20 |
| Starter | 60 | 10,000 | 100 |
| Pro | 300 | 50,000 | 500 |
| Enterprise | Custom | Custom | Custom |
Note: Burst limits allow short spikes above the per-minute limit, useful for handling traffic bursts.
Rate Limit Headers
Every response includes headers showing your current rate limit status:
| Header | Description | Example |
|---|---|---|
X-RateLimit-Limit | Max requests per window | 60 |
X-RateLimit-Remaining | Requests left in window | 45 |
X-RateLimit-Reset | Unix timestamp when limit resets | 1701234567 |
Retry-After | Seconds to wait (when limited) | 45 |
Handling Rate Limit Errors
When you exceed the rate limit, you'll receive a 429 Too Many Requests error:
Exponential Backoff Implementation
Checking Rate Limits Before Requests
Best Practices
1. Implement Exponential Backoff
Always retry rate-limited requests with exponential backoff rather than aggressive retries.
2. Monitor Headers
Track X-RateLimit-Remaining to know when you're approaching limits.
3. Use Request Queues
Queue requests and process them at a controlled rate to stay under limits.
4. Cache Responses
Cache identical requests to reduce API calls and stay under limits.
5. Distribute Load
If hitting limits, consider using multiple projects or upgrading tier.
Request Queue Implementation
Upgrading Rate Limits
If you consistently hit rate limits:
- Upgrade your subscription tier in the dashboard
- Contact sales for custom enterprise limits
- Optimize your usage patterns
- Implement caching and batching