Rate limits

Request budgets

Anonymous reads use a low-volume per-IP token bucket. API-key reads consume both the per-IP bucket and the client's rate-plan token bucket, plus a UTC-day cost-unit quota. Expensive operations declare a larger integer x-rate-cost than cached detail reads.

Responses include RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, and RateLimit-Policy; a rejected request includes Retry-After. Authenticated responses also expose X-RateLimit-Cost and X-RateLimit-Daily-Limit, X-RateLimit-Daily-Remaining, and X-RateLimit-Daily-Reset. Budgets are enforcement signals, not guaranteed throughput. Emergency global, endpoint, and client controls can temporarily lower them.

const response = await fetch(url);
if (response.status === 429) {
  const retryAfter = Number(response.headers.get("retry-after") ?? "1");
  await new Promise((resolve) => setTimeout(resolve, Math.min(retryAfter, 60) * 1_000));
}

Cache stable resources with ETags, request only the fields and endpoints you need, follow cursor limits, and avoid synchronized polling. A 304 Not Modified still protects bandwidth and origin work but consumes abuse-control capacity.

The settings dashboard reports daily request, cost, error, and rate-limit totals. A client can configure a threshold alert; the first daily crossing is durably deduplicated and emitted for notification processing. Do not distribute one credential across unrelated customers to evade isolation. Enumeration, invalid-signature floods, expensive filter abuse, and repeated payment replays trigger durable, IP-prefix-hashed security telemetry and can lead to tighter controls.