Endpoint limits
Some endpoints have an additional limit on top of the per-key rate.
These limits apply to API requests only. Your usage in the dashboard is not affected.
Requests made through the MCP server count against exactly these
limits, because each tool call is one API request made with your key.
Rate limit headers
Every response reports your current limit status, so you can pace a job without waiting for a rejection.
Headers appear only for limits that apply to the request you made.
Limits are measured over a rolling window rather than a fixed clock hour, so a
slot frees exactly one window after the request that used it. The
*-Reset headers
give you that moment, which is why you can pace a job without ever seeing a 429.
429 responses
A429 tells you which limit you reached:
Retry-After on any of these is the exact number of seconds until that moment, so
obeying it is enough.
Best practices
- Use the headers. Retry at the time given in the matching
*-Resetheader, or after the seconds inRetry-After, rather than on a fixed interval. Both are computed from the rolling window, so a fixed guess will either retry too early or wait far longer than needed. - Spread scheduled jobs. Pace exports and syncs across the window instead of firing everything at once.
- Add jitter. If several workers share one key, randomise retry timing slightly so they do not retry in lockstep.
- Cache what rarely changes. Brand and topic lists change far less often than metrics.