Rate Limits

How limits actually work today

POST /v1/auth/keys lets you set rateLimitPerMinute and rateLimitPerHour on a key, and they’re stored — but nothing currently reads them back to enforce a limit. The limit actually applied to every key today is a fixed 60 requests/minute per key, plus a fixed 300 requests/minute per organization across all of that organization’s keys combined. Setting a higher rateLimitPerMinute on your key will not raise your real ceiling. There’s also no endpoint to change these fields after a key is created — not even PATCH /v1/auth/keys/{id}/scopes, which only updates scopes.

Build against the limits below; if you need a higher ceiling, contact support rather than tuning rateLimitPerMinute/rateLimitPerHour on your key.

Limit	Value
Per API key	60 requests / minute
Per organization (all keys combined)	300 requests / minute

When a limit is exceeded

The API returns 429 Too Many Requests:

{
  "success": false,
  "error": {
    "code": "Too Many Requests",
    "message": "Rate limit exceeded",
    "reason": "Rate limit exceeded"
  },
  "meta": { "requestId": "...", "timestamp": "...", "version": "v1" }
}

Handling `429` responses

Always implement retry logic for rate-limited requests. Use exponential backoff — wait progressively longer between retries:

async function fetchWithBackoff(url, options, maxRetries = 4) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429) return response;

    const delay = Math.min(1000 * 2 ** attempt, 16000); // cap at 16s
    await new Promise((resolve) => setTimeout(resolve, delay));
  }
  throw new Error('Max retries reached');
}

import time
import requests

def fetch_with_backoff(url, headers, max_retries=4):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, timeout=30)
        if response.status_code != 429:
            return response
        delay = min(1 * (2 ** attempt), 16)
        time.sleep(delay)
    raise Exception("Max retries reached")

Best practices

Spread bursty workloads. If you need to process a large batch of records, use a queue and throttle the dequeue rate to stay within your per-minute limit rather than firing everything at once. Create separate keys per workload. A batch job hitting one key’s 60/min ceiling won’t block a different key’s interactive traffic — but remember the 300/min organization-wide cap is shared across every key in your org, so splitting keys doesn’t raise your total combined throughput. Monitor request volume. Log the response status of every API call. Alert on sustained 429 responses — it means your key limits need to be raised or your request rate needs to be reduced. Raise limits when needed. Since the fixed 60/min-per-key and 300/min-per-org ceilings aren’t currently configurable per key, contact support if your traffic needs a higher limit.

Getting Started

Core APIs

Platform APIs

How limits actually work today

When a limit is exceeded

Handling `429` responses

Best practices

​How limits actually work today

​When a limit is exceeded

​Handling 429 responses

​Best practices

How limits actually work today

When a limit is exceeded

Handling `429` responses

Best practices