Rate limits

Current limits

A single write counts against both limits. So a key making only writes maxes out at 30 requests per minute; a key mixing reads and writes maxes out at 100 total with at most 30 of them being writes.

429 response

When you hit the limit, the next request returns:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 47

{"error":"rate_limited"}

Retry-After is the number of seconds until the window resets — computed from the actual limiter state, not a fixed fallback. Wait that many seconds before retrying.

Recommended backoff

For automation scripts, follow the Retry-After header exactly — it's accurate. For interactive clients (a dashboard your subscriber users see), consider exponential backoff with jitter to avoid thundering-herd when many clients hit the limit simultaneously.

A sensible strategy:

async function callWithRetry(url, options) {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch(url, options);
    if (res.status !== 429) return res;

    const retryAfter = parseInt(res.headers.get('retry-after') || '60', 10);
    const jitter = Math.random() * 0.25 * retryAfter;
    await sleep((retryAfter + jitter) * 1000);
  }
  throw new Error('Rate limit not released after 5 attempts');
}

If you need higher limits

The default limits are intentional — they prevent accidental loops and keep infrastructure costs predictable. If your integration genuinely needs more:

• Generate a second key for the traffic-heavy use case so its limit is independent of your other integrations.
• Cache reads aggressively on your side. Facts, FAQs, policies, and team data change on human timescales (minutes to hours) — caching for 60 seconds is almost always safe.
• Batch where possible. If you're polling for new calls, list with ?since= rather than GETting each call individually.

If these don't fit your shape, reach out through the dashboard support chat and we can discuss raising your limits.

What isn't rate-limited

The API-key limiter is the only thing that returns 429 on the v1 surface. Other gates exist (malformed requests return 400, invalid keys return 401, cross-org access returns 404 — never 429). If you're seeing 429s, it's always the per-key write or read limit.