Per-key limits

LimitValueWindow
Requests600 / minutesliding 60-second window, per API key
Concurrency25 in flightsimultaneous requests, per API key

These limits apply to every current credit pack. 600/minute permits an average of 10 requests a second; bursts can still reach either ceiling. Exceeding either answers 429 RATE_LIMITED with a retry-after header holding the seconds to wait — nothing is charged. Limits apply per key, so separating workloads onto separate keys separates their budgets and their blast radius.

JavaScript — bounded backoff
async function callWithBackoff(url, init, tries = 5) {
  for (let attempt = 1; ; attempt++) {
    const res = await fetch(url, init);
    if (res.status !== 429 && res.status !== 503) return res;
    if (attempt >= tries) return res;
    const after = Number(res.headers.get('retry-after') ?? 2 ** attempt);
    await new Promise((r) => setTimeout(r, after * 1000));
  }
}

Headroom headers

Routed JSON responses normally carry the limiter’s view of your key as the request entered. Early refusals, batch wrappers, SSE and idempotent replays may omit these headers, so a client or an agent can slow down before it meets either ceiling rather than after. The two families are not aliases of each other: one is the request window, the other the in-flight cap.

HeaderMeaning
x-ratelimit-limitThe request-window cap (600 per minute).
x-ratelimit-remainingRequests still available in the current sliding window, this one included.
x-ratelimit-resetUnix time, in seconds, at which the oldest request in the window ages out and a slot returns.
x-concurrency-limitThe in-flight cap (25).
x-concurrency-remainingIn-flight slots still free as this request entered.

On a 429 the refused ceiling reads 0 remaining and retry-after says how long to wait: until the window resets for the request rate, one second for concurrency, because a slot frees the moment any in-flight request returns. If the shared limiter store is briefly unreachable, requests are still limited per instance and the figures that cannot be known are simply not sent.

The flagship fair-use ceiling

Routes eligible to use our metered commercial upstream additionally share a fair-use ceiling of 25,000 upstream attempts per rolling 30 days per account (raised to 100,000 when the configured upstream rate qualifies, unless a deployment override applies — talk to us for volume beyond that). Quota-checked live responses report x-fairuse-limit and x-fairuse-remaining when available; cached responses may omit them. Missing headers do not mean unlimited quota. When the shared quota store is degraded, any reported headroom describes the temporary budget, marked x-fairuse-degraded; crossing the ceiling answers 429 FAIR_USE_EXCEEDED with the quota spelled out in error.details, charges nothing, and tells you where the volume conversation goes. The ceiling depends on the route’s provider configuration, not its platform name. For example, some YouTube operations can be metered even when other YouTube routes use a different source.

The ceiling counts attempts, including our own retries against a flaky upstream — and it fails closed when no safe quota budget can be established: if the quota store is briefly unreachable, a small emergency budget keeps genuine traffic flowing while probes are refused.

Other 4xx/5xx you should plan for

503 with retry-after also appears when an endpoint’s upstream is failing and its circuit breaker is cooling down — same backoff handling as a 429. Per-key spending limits (set per key in the dashboard) answer 402 KEY_LIMIT_EXCEEDED. The full roster with remedies is on the Errors page.

First call in under a minute

150 free credits and a ready-made key the moment you sign up. No card.