429 Too Many Requests
What a 429 or "Too many attempts" means, which requests can trigger it, and how to recover without making it worse.
On this page
Symptom#
- A page says Too many attempts. Wait a little and try again., or Too many attempts. Try again in a wait such as 45 seconds, 57 minutes or 2 hours.
- A page titled Too many attempts with the text Wait a little and try again.
- A message that names the cause, for example We have already sent the most emails allowed to this address for now. or You have asked for too many sign-in codes., with a link Why does this happen? and a line Reference: and a code.
- An HTTP response with status 429 from the token endpoint, the pushed authorization request endpoint, userinfo or the account API.
- In an application using the SDK, an
OAuthEndpointErrorwhosereasonisrate_limited, withretryAfterSeconds.
Likely causes#
Identity limits how fast one person, one client or one address can try something, so that guessing and flooding do not work. The exact limits are not published and can change. These are the kinds of request a limit applies to.
| Where | Typical trigger |
|---|---|
| Sign-in and second-step pages | Repeated wrong passwords or codes, or many sign-in attempts in a row. |
| Email-sending steps | Asking for sign-in links, codes or recovery messages again and again. Only a limited number of messages are sent to one address in a short while, and every request for a message to that address counts, whether or not an account exists (a request that is itself turned away does not). The page says so and how long to wait; see Why a message may never be sent. |
| Lost-passkey email code | Asking for the Email me a code instead code more than twice in a day. The wait can be hours. |
| Sensitive account actions | Repeated failed confirmations, or many credential changes in a short time. |
| Token and pushed authorization endpoints | An application that retries in a tight loop, or sends many failing requests. |
| Client authentication | A run of failed client assertions, or a reused assertion. |
| Userinfo and the account profile | A burst of requests with tokens that do not verify. A token that does verify is answered. |
| A personal access token | Where personal access tokens are accepted as bearers (flag pat_bearer_api, default OFF), the token has spent its hourly budget on the profile. The body says the token has spent its hourly budget. |
A limit is not a lockout. There is no permanent lock on an account because of failed attempts. When the budget for one account runs out, the owner can be told by email.
Some limits are not 429. Sign-up is temporarily limited means too many accounts were created today, and it clears on its own. We have reached the limit for sending email today, so no message can be sent right now. means the whole service has used its daily allowance of messages (status 503); it clears at midnight UTC.
What to check#
- Read the
Retry-Afterheader, or the wait on the page. The header is a whole number of seconds, at least 1; the page says the same wait in seconds, minutes or hours, rounded up. - Ask what you did just before: a loop, several tabs, a script, a password manager filling the wrong password.
- For an application, look at its logs for repeated failures that came before the 429. A wrong client assertion or an expired DPoP proof makes the next call fail again and counts against you.
- Check that the SDK is not being called again by your own retry code. The relying party and service client retry a 429 a bounded number of times (three attempts by default), so a retry loop of your own multiplies the requests. They never retry a 5xx. Set
retry: { maxAttempts: 1 }if you want to own the policy.
Fix#
- People. Wait for the time shown (it is rounded up, so it is never short), then try once. Do not keep pressing the button. If you are locked out of a password, use Forgot password?, or Use a recovery code where your organization allows it.
- Applications. Wait at least
Retry-Afterseconds, then retry with a growing delay. Fix the failing cause first, for example the clock, the redirect address or the key, because retrying a request that will fail only makes the wait longer. Cache the discovery document and your tokens instead of fetching them for every request. - Many people behind one address. Limits that count by address can be reached by a shared office or network. Contact the owner of the application if it keeps happening.
- Personal access tokens. The budget resets with time. Use fewer calls, or use a signed-in session through the SDK for heavy work.
What not to do#
- Do not try to get around a limit by switching networks or accounts. It does not make a legitimate request succeed, and a run of failures is what the limits are there to slow down.
- Do not hard-code a wait. Use the header.