Rate Limiting
Rate limits use Cloudflare Workers Rate Limiting bindings declared in wrangler.toml. The namespace_id values are arbitrary account-unique numbers, not provisioned resources, so leave them alone.
| Binding | Limit | Key | Protects |
|---|---|---|---|
FORM_SUBMISSION_RATE_LIMITER |
5 / 60 s | Client IP | Public form submissions |
AUTH_RATE_LIMITER |
10 / 60 s | Client IP | POST requests under /api/v1/auth/*: sign-in, sign-up, sign-out, verification, two-factor. GET requests such as get-session are not limited |
RECOVERY_RATE_LIMITER |
3 / 60 s | Client IP | Password-reset request and confirm, recovery-code redemption, and the break-glass owner recovery endpoint |
PUBLIC_CONTENT_RATE_LIMITER |
300 / 60 s | Client IP | Every /api/v1/public/* route. A loose baseline against floods of uncached slugs |
ADMIN_EMAIL_RATE_LIMITER |
10 / 60 s | Staff user id | Email sent from the admin, including submission replies |
Exceeding a limit returns 429. The recovery limit is the tightest because success at any of those routes changes a password.
Behind a proxy
Section titled “Behind a proxy”A limit keyed on the client IP sees the proxy’s address when requests come through a same-origin proxy, so all visitors share one bucket. Set the same TRUSTED_PROXY_SECRET on the API and on your website and pass it to createCmsProxy. The API then accepts the visitor IP the proxy forwards, but only when the secret matches. Unset, the forwarded headers are ignored.
Server-side content fetches from a busy website also arrive from the website Worker’s address and can reach the 300-per-minute public limit. Cache those fetches.