Rate limits cap the volume of auth-related requests your project will accept per time window. They protect against credential stuffing, runaway scripts, and accidental self-DoS — without you having to write any middleware.

Every Eurobase project gets a sane platform-wide default. You only need to touch this page if you want to tighten or loosen a specific knob.

Where to find it

In the console: Auth → Rate Limits tab. The page shows the knobs below, plus an "IP Address Forwarding" toggle.

The knobs

• Signup / sign-in rate — how many /v1/auth/signup + /v1/auth/signin requests per 5-minute window per IP. Default: 8 per 5 min.
• Token refresh rate — how many /v1/auth/refresh calls per 5 min per IP. Higher than the others because legitimate SDK clients refresh proactively. Default: 150 per 5 min (~ 1800/hour).
• Token verification rate — how many phone-OTP, magic-link sign-in, password-reset and email-verification calls per 5 min per IP. Default: 30 per 5 min.
• Auth emails — there's no hourly cap per project on the platform sender today (the "emails per hour" setting isn't enforced, so the console doesn't show it). Per address: 3 magic links and 3 password-reset emails per 15 minutes, one verification resend per 5 minutes. Per client IP: 60 password-reset and 60 verification emails an hour, 300 magic-link requests an hour.
• SMS per hour — cap on outbound auth SMS (phone OTP) per rolling hour. Default: 30/hour; an override can be at most 10.
• IP Address Forwarding (Trust Proxy) — when on, the rate limiter takes the client IP from X-Forwarded-For instead of the connection. Leave it off unless Eurobase support asks you to turn it on. Default: off.

Setting them up

1. Open Auth → Rate Limits.
2. For each knob, leave blank to keep the platform default, or enter your value. The placeholder text shows what the default is.
3. For a launch or migration day, set sign-up / sign-in to 30 and token verification to 150.
4. Hit Save changes. The new limits apply within a few seconds — no redeploy needed.

What an over-quota response looks like

When a request goes over a limit, the SDK receives HTTP 429 Too Many Requests with a Retry-After header naming the number of seconds the client should wait. Your app can surface a friendly message; the limit window slides, so retrying after the indicated delay succeeds.

// SDK example: handle 429 cleanly
try {
  await eb.auth.signIn({ email, password })
} catch (err) {
  if (err.status === 429) {
    const retryAfter = parseInt(err.headers['retry-after'] || '60', 10)
    showToast(`Too many attempts. Try again in ${retryAfter}s.`)
    return
  }
  throw err
}

Tuning guidance

• Just launched, small audience. Leave the defaults — they're set for a project receiving up to a few thousand signups/day.
• Growing fast, lots of token refreshes. Raise the token-refresh knob if you see legitimate 429s. The default (~1800/hour/IP) handles most SDK clients, but if your app refreshes more aggressively, double or triple it.
• Phone-first product (SMS OTP). Raise SMS/hour to your provider quota. The default is conservative so an accidental script doesn't bleed your GatewayAPI budget.
• Outgrowing the platform email cap. See the next chapter (Custom SMTP) — bringing your own SMTP provider removes the platform "emails per hour" cap entirely for sends through your provider.

What rate limits don't do

These knobs only cap auth-flow traffic. They do not gate your SDK reads/writes against the database or storage — those are governed by your plan's request budget (Settings → Usage). For application-level rate limiting on your own endpoints, build it into your edge functions or your app middleware.