CoreCited
API docs menu

Rate limits

Each workspace gets a number of requests per minute, set by its plan and shared by all of its keys.

Limits by plan

PlanLimit
FreeNo API access (402)
StarterNo API access (402)
GrowthNo API access (402)
Agency60 requests / minute
Scale120 requests / minute
Enterprise300 requests / minute

How the limit is counted

  • Per workspace, not per key. Creating more keys does not raise the limit.
  • Per calendar minute. The count resets at the start of every minute (UTC), not on a sliding window.
  • Every authenticated request counts, including ones that end in 404 or 500. Requests refused with 401 or 402 are rejected before the limiter and do not count.
  • The count is atomic in the database, so parallel requests cannot slip past it. With a limit of 60, the 61st request in a minute is refused however many arrive at once.

Response headers

Every response to an authenticated request carries the current state:

HeaderMeaning
X-RateLimit-LimitRequests allowed per minute for this workspace.
X-RateLimit-RemainingRequests left in the current minute.
X-RateLimit-ResetUnix time in seconds when the current minute ends.
Retry-AfterOnly on 429: seconds to wait before retrying.

When you hit the limit

The API answers 429 with the error code rate_limited. Wait the number of seconds in Retry-After, then retry.

async function getWithRetry(url, init, attempts = 3) {
  for (let i = 0; i < attempts; i++) {
    const res = await fetch(url, init);
    if (res.status !== 429) return res;
    const wait = Number(res.headers.get("Retry-After") ?? "1");
    await new Promise((r) => setTimeout(r, wait * 1000));
  }
  throw new Error("Still rate limited after retries");
}
You should rarely get near the limit. The data changes once a week, so a daily sync that lists brands and reads each endpoint once needs a handful of requests per brand. If you need more, cache the responses. They will not change until the next cycle.