Rate limits

How limiting works

Requests are rate-limited over a rolling one-minute window. Integrations — API keys and tokens from POST /api/v1/auth/login — are limited per organisation: your per-minute allowance is set by your plan, and 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.

People working in PIE's own apps are limited differently, because a single page makes many requests: each signed-in user has their own allowance of 600 requests per minute, and all of an organisation's signed-in users together may use up to five times the plan's allowance. Browser sessions therefore never use up the quota your integrations depend on.

Sign-in attempts are limited separately and count failures only: ten failed attempts for one account from one IP address, or fifty from one IP address across accounts, within 15 minutes. Successful sign-ins never count.

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);
  }
}