Skip to main content

Rate limits

Each API key has a request limit that depends on your Space's plan tier.

The limit is counted per key, in one-minute windows. The number of requests per minute comes from your Space's plan.

v1 — expanding

The per-plan figures are not published yet. Read your own limit from the RateLimit-Limit header. If your plan has no figure set, the limit is 0 and every call answers 429 rate_limited: the API is never unlimited. Contact XQUARE support if that happens.

Headers on every response​

HeaderMeaning
RateLimit-LimitRequests allowed per minute for this key
RateLimit-RemainingRequests left in the current one-minute window
RateLimit-ResetSeconds until the window resets

When you hit the limit​

You get 429 Too Many Requests (code: rate_limited) with a Retry-After header — the number of seconds to wait. Wait at least that long, then retry with the same Idempotency-Key.

HTTP/1.1 429 Too Many Requests
Retry-After: 12

Good practice:

  • Back off on every 429; never retry in a tight loop.
  • Spread bulk jobs (imports, nightly syncs) over time.
  • Prefer webhooks over polling — they cost you no requests.

Limits vs. credits​

A rate limit caps how fast you call. Your plan's monthly action allowance caps how many actions you take per calendar month (Asia/Jakarta). A sponsor redemption counts against the allowance and costs its credits; when the allowance is used up you get 429 allowance_exhausted with Retry-After (seconds to the next month) and nothing is charged.

Key verifications are also limited per IP address, before the key is checked: every request whose key is not already cached counts, valid or not, against a budget of 30 verifications per IP address per minute. A verified key stays cached for about a minute, so a steady integration spends about one verification per key per minute; many processes or keys behind one address share the budget. Over it you get 429 rate_limited with Retry-After.

Last updated on