Rate limits

Atlas rate-limits to protect instances from abuse and credential-stuffing. Limits apply per secret key on the BAPI, and per IP on the sensitive FAPI flows (sign-in, sign-up create, verification-code sends).

The 429 response

When you exceed a limit you get 429 with the RATE_LIMITED code and a Retry-After header (seconds). The wait is also in meta.retry_after:

{
  "errors": [
    {
      "code": "RATE_LIMITED",
      "message": "Too many requests. Please retry later.",
      "meta": { "retry_after": 30 }
    }
  ]
}

Back off and retry after the indicated delay; jitter your retries so a fleet does not synchronize.

Sensitive-flow limits

Some flows are limited more tightly by design and independently of the global budget — for example verification-code reissue is capped at 1 per 30 seconds and 5 per hour per address. Exceeding these returns TOO_MANY_ATTEMPTS rather than a plain RATE_LIMITED.

Tuning the policy

The per-instance budgets are configurable (sign-in / sign-up create per IP, and BAPI per key):

# Read the policy and its bounds
curl https://api.atlas.dev/v1/rate_limit_policy \
  -H "Authorization: Bearer sk_live_xxx"     # scope: rate_limit:read

# Tighten it (values are bounded — protection cannot be disabled or set to self-DoS)
curl -X PATCH https://api.atlas.dev/v1/rate_limit_policy \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "…": "…" }'                            # scope: rate_limit:write

Defaults equal the built-in fixed limits; a lower value tightens the limiter. You cannot raise a budget high enough to disable protection.

Related controls

• Network ACLs (/v1/network_acls) — per-instance IP allow/deny rules that gate access before rate limiting even applies.

• Attack protection (/v1/attack_protection) — brute-force lockout and breached-password checks.

• Adaptive (risk-based) MFA (/v1/risk_based_mfa) — step up when a sign-in looks risky.