Skip to content
P
Back to Guides

Rate limits

Per-plan limits and the X-RateLimit-* / Retry-After response headers.

How limiting works

Requests are rate-limited per organisation, over a rolling one-minute window. Your per-minute allowance is set by your plan; all of an organisation's keys share the same window. Sandbox traffic is metered in a separate bucket, so exploring the API never eats your production quota.

Response headers

Every response reports your current standing:

  • X-RateLimit-Limit — the maximum requests allowed in the window.
  • X-RateLimit-Remaining — requests still available in the current window.
  • Retry-After — sent only on a 429; the number of seconds to wait before retrying.

Handling 429 Too Many Requests

When you exceed the limit, PIE responds 429 with the standard error envelope and a Retry-After header:

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

{ "error": { "code": "RATE_LIMITED", "message": "Too many requests" } }

Back off for at least Retry-After seconds before retrying. A robust client honours the header and adds jitter to avoid a synchronised retry storm:

async function call(url, key) {
  for (let attempt = 0; ; attempt++) {
    const res = await fetch(url, { headers: { "X-API-Key": key } });
    if (res.status !== 429) return res;

    const wait = Number(res.headers.get("Retry-After") ?? 1);
    await sleep((wait + Math.random()) * 1000);
  }
}

Watch X-RateLimit-Remaining and slow down proactively rather than waiting for a 429. Repeated 429s on an API key raise a rate-limit warning notification to your org admins.