Skip to main content

Rate Limits

All API endpoints are rate-limited using a sliding window algorithm. Limits are enforced per agent (for SDK endpoints) or per IP/user (for dashboard and auth endpoints).

Limits by Endpoint

Auth endpoints enforce two independent limits: per-IP and per-account. The per-account limit prevents credential stuffing attacks that rotate source IPs. Both limits must pass for a request to proceed.

Response Headers

Every API response includes rate limit headers:

Rate Limited Response

When a request is rate limited, the API returns HTTP 429:

Retry Strategy

The SDK automatically retries 429 and 5xx responses only for read-only calls and writes that are protected by stable idempotency:
  • Up to 3 retries with exponential backoff
  • Respects Retry-After headers
  • Backoff: 1s, 2s, 4s (capped at 10s)
  • Client errors (4xx except 429) are not retried
  • Payment execution, card writes, protocol records, and admin mutations are not automatically retried; reconcile their status before trying again
For manual retry logic: Only wrap read-only or explicitly idempotent operations. Never use a generic retry wrapper around payment execution or another non-idempotent write.

Behavior on backend errors

Rate limiting uses a sliding window counter backed by Redis in production. If a Redis call fails, the limiter degrades to a per-instance in-memory counter so requests keep flowing while abuse stays bounded; it does not fail closed. When Redis is not configured at all (development), the in-memory counter is used from the start.