Rate limits

Qeet ID enforces distributed rate limiting with a Redis-backed atomic token-bucket keyed per IP, tenant, user, and API key. Because the counter lives in Redis, limits hold across replicas — not per-process. CSRF protection and security headers are applied alongside.

How it works

• Token bucket, evaluated atomically in Redis, so concurrent requests across nodes share one ceiling.
• Keyed by IP, tenant, user, and API key, so abuse on one dimension doesn't starve others.
• Layered with per-account lockout on auth endpoints to blunt credential stuffing.

The 429 response

When a limit is exceeded, Qeet ID returns 429 with a Retry-After header and the standard error envelope:

{
  "error": {
    "code": "rate_limited",
    "message": "too many requests"
  }
}

HTTP/1.1 429 Too Many Requests
Retry-After: 27

Honor Retry-After and back off. The SDKs do this automatically — 429 (and 5xx on idempotent calls) are retried with backoff. See API → Errors.

CSRF & security headers

Browser-facing endpoints are CSRF-protected (the hosted-login SSO cookie flows are CSRF-aware; SAML ACS / IdP-POST endpoints are explicitly CSRF-exempt because they're signature-validated). Standard security headers are set on responses.