Two allowances per key
Both are set on the key when it is issued, so two keys can have different allowances. The monthly quota can be unlimited.
Read your per-minute allowance from the
X-RateLimit-Limit header on any response. The monthly quota is agreed when the key is issued and is not reported in a header. If you do not know yours, ask support.
The per-minute window is a fixed clock minute, not a rolling one. The allowance refills when the minute ends, at the time in X-RateLimit-Reset.
The rate limit headers
Every response to a request the API counted carries three headers, on a success and on an error alike:
All three describe the per-minute window. None of them describes the monthly quota.
Responses sent before the request is counted do not carry them:
401, 405 and 503 api_unavailable. Do not expect them on 503 rate_limit_unavailable either: it is usually sent before the request could be counted. Treat them as optional on any 5xx.
When you go over
Retry-After, in whole seconds. Wait that long before you send the request again.
A request refused by the per-minute limit does not count towards the monthly quota.
On 429 quota_exceeded the X-RateLimit-* headers still describe the minute window. Use Retry-After, not X-RateLimit-Reset, to know when the quota comes back. Do not sleep through it. Stop the job and schedule it for the new month, or ask for a higher quota.
What counts
Every authenticated request is charged to the per-minute allowance. That includes requests the API goes on to refuse: a400 for a bad parameter, a 403 for a missing scope, a 404 for an id it cannot find, a 413 for an oversized body. A replayed idempotent request counts too.
A request that the per-minute limit lets through is then charged to the monthly quota. There is one exception: 403 tier_not_entitled, answered when the key’s organisation has lost API access, is charged to the minute only.
A 401 is not charged to any key. Failed authentication is throttled by client address instead. After too many 401 responses from one address in a minute, that address gets 429 rate_limited for the rest of the minute, even with a valid key. The X-RateLimit-* headers on that response describe the address’s allowance of failed attempts. See Authentication.
When the API cannot count, it refuses
The API never serves a request it could not meter. If it cannot check your key or count the request, it refuses the request instead. Every503 carries Retry-After.
Back off and retry
This helper sends one request and retries it on429 and 503. It waits for Retry-After. If the header is missing, it falls back to exponential backoff with jitter. It gives up after a fixed number of attempts, and it raises instead of sleeping when the wait is long, which is what a spent monthly quota looks like.
Retrying a read is always safe. Before you retry a write, give it an Idempotency-Key.
Staying under your limits
- Use the rollup.
GET /orgs/{orgId}/brands/summaryreturns one row per own brand, with its latest score, the change since the previous one, sentiment, share of voice and scan freshness. That is one request instead of one per brand. - Poll the change token, not the data.
changed_aton each summary row, andlast_scan_changed_aton a brand, move whenever something changed for that brand. Read results again only when the value has moved. See Data model. - Ask for full pages. A
limitof 200, or 1000 on the mentions endpoint, fetches the same data in fewer requests. While a scan is running, smaller pages are the better choice for results and mentions. See Pagination and date windows. - Let webhooks tell you. Platform partners can subscribe to
scan.completedand stop polling for new results. See Webhooks.