Skip to content

Rate Limits

Understand the rate limits for the Trakkr API and how to handle them gracefully in your application.

Overview

The Trakkr API limits how many requests it accepts per minute, so one busy caller cannot slow the service down for everyone else.

The limits are generous for normal use. If you keep hitting them, batch your calls or cache what you already fetched.

How the limit works

There is one kind of limit: a per-minute count on each endpoint, listed in the table below. It is the same on every plan. There is no burst allowance, no daily quota, and no higher tier that lifts these numbers. API access requires the Scale plan ($500/mo) or higher, but the plan does not change the per-minute figures.

Limits are counted per calling IP address, not per API key. Two keys calling from the same server share one budget, and so do all the services behind one NAT gateway or egress proxy. If a heavy job needs the full limit to itself, give it its own egress IP.

API keys can only be generated on the Scale plan or higher. Free and Growth plans do not include API access. Upgrade your plan to get started.

Per-Endpoint Limits

Different endpoints have different rate limits based on their computational cost. Write operations and resource-intensive endpoints have stricter limits.

EndpointMethodRate LimitNotes
/get-brandsGET60/min
/get-brands/marketsPOST30/minMarket limit per plan
/get-brands/marketsDELETE30/min
/get-brands/aliasesPUT30/min
/get-scoresGET60/min
/get-promptsGET60/min
/get-promptsPOST30/min
/get-promptsPUT30/min
/get-promptsDELETE30/min
/get-citationsGET60/min
/get-competitor-dataGET60/min
/get-rankingsGET60/min
/get-modelsGET60/min
/get-opportunitiesGET60/min
/get-perceptionGET60/min
/get-perceptionPOST10/minTriggers new analysis
/get-content-ideasGET60/min
/get-content-ideasPOST10/minTriggers refresh
/get-reportsGET60/min
/get-reportsPOST5/minGenerates PDF report
/crawler/overviewGET60/min
/crawler/liveGET60/min
/crawler/pagesGET60/min
/crawler/accessGET60/min
/crawler/access/preview-fixPOST30/minPreview only
/crawler/verification-pingPOST30/minEditor access required
/crawler/submit-to-searchPOST30/minEditor access required
/crawler/submit-to-search/statusGET60/min
/narrativesGET60/min
/narrativesPOST10/min
/narrativesPATCH30/min
/narrativesDELETE30/min
/diagnosePOST10/min200/mo quota (Scale)
/diagnoseGET60/min
/get-actionsGET60/min
/get-action-statsGET60/min
/manage-actionPOST30/minEditor access required
/get-auditsGET60/min
/get-audit-findingsGET60/min
/get-opportunity-poolGET60/min
/commit-opportunityPOST30/minEditor access required
/get-resultsGET60/min
/get-pagesGET60/min
/get-page-analysesGET60/min
/prismGET60/min
/exportGET10/min
Read endpoints (GET) generally allow 60 requests/minute. Write and compute-intensive endpoints (POST for reports, diagnose, perception) have stricter limits. The report generation endpoint has the strictest limit at 5/min due to its computational cost.

Handling Rate Limits

When you go over, the API returns 429 Too Many Requests. The body holds one error string naming the limit you hit, for example Rate limit exceeded: 60 per 1 minute. Note that this is the one error that does not use the usual detail field.

Responses carry no rate limit headers. There is no X-RateLimit-Remaining, X-RateLimit-Limit, X-RateLimit-Reset or Retry-After to read, on any response including the 429. Plan around the published limits instead of measuring what is left.

Wait a fixed minute

Windows are one minute long. On a 429, sleep 60 seconds and try once more, rather than retrying straight away.

Back off if it keeps happening

If the retry is limited too, grow the wait and add jitter, so a fleet of workers does not all come back at the same moment.

Count your own requests

With no remaining counter to read, track your call rate on your side and throttle before you reach the limit. Remember the budget is shared by everything on the same IP address.

Exponential Backoff

Exponential backoff means each retry waits longer than the last. Start above the one-minute window, then double, and add random jitter so clients do not all retry at exactly the same time:

Exponential Backoff
Code language
1# Implement exponential backoff in shell
2attempt=1
3max_attempts=5
4
5while [ $attempt -le $max_attempts ]; do
6 response=$(curl -s -w "%{http_code}" \
7 -H "Authorization: Bearer $TRAKKR_API_KEY" \
8 'https://api.trakkr.ai/get-brands')
9
10 status=$(echo "$response" | tail -c 4)
11
12 if [ "$status" -eq 200 ]; then
13 echo "Success!"
14 break
15 elif [ "$status" -eq 429 ]; then
16 sleep_time=$((2 ** $attempt))
17 echo "Rate limited. Retrying in ${sleep_time}s..."
18 sleep $sleep_time
19 attempt=$((attempt + 1))
20 else
21 echo "Error: $status"
22 break
23 fi
24done

Best Practices

1

Batch operations when possible

Use bulk endpoints to create or update multiple resources in a single request.

2

Cache responses locally

Avoid redundant API calls by caching frequently accessed data that doesn't change often.

3

Use webhooks for real-time updates

Instead of polling, subscribe to webhooks to receive push notifications for events.

4

Queue and throttle requests

Implement a request queue with throttling to smooth out bursts and stay within rate limits.

Need higher limits? Contact us at hey@trakkr.ai to discuss your use case.

Code example

Handling Rate Limits
Code language
1# A 429 names the limit you hit. No rate limit headers are sent.
2curl -i -H 'Authorization: Bearer $TRAKKR_API_KEY' \
3 'https://api.trakkr.ai/get-brands'
4
5# HTTP/2 429
6# Content-Type: application/json
7# {"error": "Rate limit exceeded: 60 per 1 minute"}
429 Too Many Requests
1{
2 "error": "Rate limit exceeded: 60 per 1 minute"
3}
Press ? for keyboard shortcuts