Rate Limits
Understand the rate limits for the Trakkr API and how to handle them gracefully in your application.
Overview
The Trakkr API implements rate limiting to ensure fair usage and maintain stability for all users. Rate limits are applied on a per-API-key basis.
Rate Limit Tiers
API access requires the Scale plan ($399/mo) or higher. Your rate limit depends on your plan:
| Plan | Requests/min | Burst | Daily Limit |
|---|---|---|---|
| Scale | 60 | 100 | 10,000 |
| Enterprise | 300 | 500 | Unlimited |
| Test Keys | 20 | 30 | 1,000 |
Per-Endpoint Limits
Different endpoints have different rate limits based on their computational cost. Write operations and resource-intensive endpoints have stricter limits.
| Endpoint | Method | Rate Limit | Notes |
|---|---|---|---|
/get-brands | GET | 60/min | |
/get-brands/markets | POST | 30/min | Market limit per plan |
/get-brands/markets | DELETE | 30/min | |
/get-brands/aliases | PUT | 30/min | |
/get-scores | GET | 60/min | |
/get-prompts | GET | 60/min | |
/get-prompts | POST | 30/min | |
/get-prompts | PUT | 30/min | |
/get-prompts | DELETE | 30/min | |
/get-citations | GET | 60/min | |
/get-competitor-data | GET | 60/min | |
/get-rankings | GET | 60/min | |
/get-models | GET | 60/min | |
/get-opportunities | GET | 60/min | |
/get-perception | GET | 60/min | |
/get-perception | POST | 10/min | Triggers new analysis |
/get-content-ideas | GET | 60/min | |
/get-content-ideas | POST | 10/min | Triggers refresh |
/get-reports | GET | 60/min | |
/get-reports | POST | 5/min | Generates PDF report |
/get-crawler | GET | 60/min | |
/narratives | GET | 60/min | |
/narratives | POST | 10/min | |
/narratives | PATCH | 30/min | |
/narratives | DELETE | 30/min | |
/diagnose | POST | 10/min | 200/mo quota (Scale) |
/diagnose | GET | 60/min | |
/prism | GET | 60/min | |
/export | GET | 10/min |
Rate Limit Headers
Every API response includes headers to help you track your current rate limit status:
X-RateLimit-LimitMaximum number of requests allowed per window
X-RateLimit-RemainingNumber of requests remaining in the current window
X-RateLimit-ResetUnix timestamp when the rate limit window resets
Retry-AfterSeconds to wait before retrying (only on 429 responses)
Handling Rate Limits
When you exceed the rate limit, the API returns a 429 Too Many Requests status code. Your application should handle this gracefully:
Respect Retry-After
Always check the Retry-After header and wait the specified time before retrying.
Exponential Backoff
Implement exponential backoff with jitter to avoid thundering herd problems when recovering from rate limits.
Monitor Remaining Quota
Check X-RateLimit-Remaining proactively and slow down requests as you approach the limit.
Exponential Backoff
Exponential backoff is a strategy where you progressively increase the wait time between retries. Adding random jitter prevents all clients from retrying at exactly the same time:
Best Practices
Batch operations when possible
Use bulk endpoints to create or update multiple resources in a single request.
Cache responses locally
Avoid redundant API calls by caching frequently accessed data that doesn't change often.
Use webhooks for real-time updates
Instead of polling, subscribe to webhooks to receive push notifications for events.
Queue and throttle requests
Implement a request queue with throttling to smooth out bursts and stay within rate limits.
