Rate limits
Keyed per API key (not per IP, not per org). Generous for normal integration traffic; tight enough to catch runaway scripts.
Current limits
| Endpoint class | Limit | Scope of counter |
|---|---|---|
| Read endpoints (GET) | 100 / minute | per API key |
| Write endpoints (POST, PUT, PATCH, DELETE) | 30 / minute | per API key |
Reads and writes are tracked on independent counters — a write doesn't consume your read budget, and a read doesn't consume your write budget. So a single key can make up to 100 reads and 30 writes per minute (130 requests total in the right mix). A key making only writes tops out at 30 per minute; a key making only reads tops out at 100.
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-Afteris the number of seconds until the window resets, computed from the limiter's state (it falls back to 60 only if the window cannot be read). 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, 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.