Submission rate limits.

What triggered this

You submitted the same flow more times in a short window than Citadel allows. The limit is per-user (or per-IP for unauthenticated surfaces); the response is HTTP 429 with the rate_limited code.

The limits

• Org creation — 10 / day / user. Counter resets 24 hours after the first attempt of the window.
• Avatar upload — 10 / day / user, same shape as org creation.
• Auth probe (the public "is this email known" lookup that backs the sign-in funnel) — 30 / minute / IP and 10 / minute / email.
• OAuth public client-info — 60 / minute / IP. The endpoint is CDN-cached for 5 minutes; routine consent-screen rendering never approaches this cap.
• Contact form — small window per IP, scoped to the public surface.

Why these caps exist

Each cap is sized for the legitimate use case: a developer registering one or two orgs rarely hits a 10/day limit; a user uploading an avatar a few times to find a flattering crop won't get caught. Caps exist to keep abuse surfaces (storage churn, slug-squatting scripts, bulk OAuth-app spam) from running unbounded.

What to try

• Wait. Most caps reset within the hour for per-minute limits and within 24 hours for per-day limits.
• If you genuinely need the action right now (e.g. shipping a release, locked out of an OAuth flow), contact support and quote E-rate_limited — operators can verify the request is legitimate and lift a per-user counter.
• If you're a developer hitting a public-API limit programmatically, back off exponentially rather than retrying tightly. The CDN cache layer handles read-heavy traffic; you don't need to fetch the same response twice in five minutes.