Rate limits

Every request consumes one token from a sliding-window bucket. Limits scale with your API key's tier.

Per-tier limits

Tier	Requests / minute
starter	600
pro	3,000
scale	10,000
enterprise	30,000

Unauthenticated or session-cookie requests fall back to the global 600/min IP-bucket.

Bucket key

Auth	Bucket
API key	per-key (key:<api_key_id>)
Session cookie	per-user (falls back to IP)
Anonymous	per-IP

The tier is resolved from the API key itself, regardless of middleware order. Promote a key via the dashboard or via billing webhook; new limits take effect on the next request.

Response headers

Every response includes:

Header	Type	Meaning
X-RateLimit-Limit	integer	Requests allowed per minute for this key.
X-RateLimit-Remaining	integer	Requests left in the current window.
X-RateLimit-Reset	unix seconds	When the window resets.
X-RateLimit-Tier	string	starter/pro/scale/enterprise. Only present on API-key auth.
Retry-After	seconds	429 only. Wait this long before retrying.

429 body

json
{  "error": "Too many requests",  "code": "RATE_LIMITED",  "request_id": "req_abc",  "retry_after": 12}

Auto-retry (SDK and CLI)

The SDK and CLI auto-retry once on 429 when retry_after ≤ 30s. For longer suggested delays they surface the error so your code can decide.

Watching headroom

In an agent or polling loop, peek at X-RateLimit-Remaining and back off proactively:

ts
new RogerIQ({  apiKey: process.env.RIQ_API_KEY!,  projectId: process.env.RIQ_PROJECT_ID!,  onResponse: (meta) => {    if (meta.rateLimit && meta.rateLimit.remaining < 20) {      console.warn("Slowing down — only", meta.rateLimit.remaining, "left");    }  },});

Burst protection

The window is sliding (per-second resolution), so a burst of 100 requests in 100ms followed by an idle minute counts the same as 100 spread out. There is no separate "burst" limit.

Increasing your tier

• Pro / Scale: change plan in Settings → Billing. Tier on existing keys updates automatically.
• Enterprise: contact sales. Custom limits, dedicated quota.