Rate limits

120 requests per minute, per key. The counter is per key, not per IP — two keys on the same account have separate buckets, and sitting behind a proxy changes nothing.

Over the limit: 429, with Retry-After in seconds both in the header and in the body.

json

{
  "error": {
    "message": "Too many requests.",
    "statusCode": 429,
    "retryAfter": 37
  }
}

Aggregate cache

/v1/sales/metrics and /v1/creatives/ranking are served from a 30-second cache. Polling them in a loop brings no fresher number, it only burns your limit.

Reading the ranking is also what schedules the refresh of the numbers that come from TikTok and Meta, and that has its own window — platformMetrics.nextAttemptInSeconds says how long is left. Looping does not bring it forward.

/v1/sales is not cached: it is how you discover new sales.

To follow sales in near real time, call /v1/sales with a small limit and a stored cursor, instead of re-scanning the whole window every minute.

Quota vs rate limit

Two different limits, and the difference is what to do. The rate limit is per minute and waiting fixes it: 429, honour Retry-After. The quota is per period and waiting does not fix it: 403 API_QUOTA_EXCEEDED, contact support.

There is no quota configured today: no account receives this error. It is documented because, the day a ceiling is set, it starts applying with no contract change — and your integration already knows how to handle it.

Window ceiling

No call accepts a window longer than 90 days. For longer periods, chain calls. With no from/to, the default is the last 30 days.