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.