Rate Limits
Rate Limits
Vault enforces rate limits to protect accounts from brute force, the platform from abuse, and your users from noisy neighbors. This page explains which limits apply to your integration, what happens when one is exceeded, and how to respond correctly so your users never notice.
If your application handles the behavior described here, you will not run into problems. If it does not, the most likely symptom is intermittent 429 responses that break user sessions.
How Limits Are Measured
Limits are applied per identity, and the identity depends on the endpoint:
- Authentication endpoints (login, register, password reset etc) are limited per account(the email address or user they act on).
- Token endpoints are limited per user session.
- API v1 endpoints are limited per user and per application (per client) simultaneously.
- OAuth flow endpoints (authorize, callback) are limited per session and per redirect target.
A limit exceeded by one identity does not affect any other. Ten thousand requests from other users do not count against your users, and vice versa.
Vault also applies an additional backstop per source address on authentication endpoints. It exists to stop automated attacks and is sized so that normal traffic(including users sharing an office or mobile network) never encounters it.
The 429 Response
When a limit is exceeded, Vault responds with:
HTTP/1.1 429 Too Many Requests Content-Type: application/json
{ "message": "Your API usage was marked as abusive and now you've been blocked. Try again in 15 minutes", "statusCode": 429 }
The response tells you how long the block lasts. Your application should:
- Stop retrying immediately. Retrying during a block does not clear it faster and may extend it.
- Wait the indicated duration, then retry once.
- Don’t treat a 429 as fatal. The user’s session and tokens remain valid. Nothing is lost, you only need to pause.
Authentication Limits
These limits protect user accounts from guessing and abuse. They are counted against the account, not your application, so every integration that redirects through Vault shares the same per-account budget.
| Endpoint | Scope | Limit |
|---|---|---|
| Login attempts | per account | 10 per 1 minutes |
| Account registration | per email | 5 per hour |
| Email verification resend | per email | 5 per 10 minutes |
| Password change request | per email | 3 per hour |
| Password change submission | per user | 3 per hour |
| Account removal request | per email | 3 per hour |
Failed Login Attempts
Failed login attempts are counted per account. After ten failures within one minute, further attempts for that account are temporarily blocked. A successful login resets the counter, so users who occasionally mistype their password are never affected.
If your application performs automatic login attempts (for example, an embedded login form with retries), it must stop retrying after a failed response and let the user try again manually. An automatic retry loop can lock a user out of their own account.
OAuth Flow Limits
These limits govern the authorization flow between your application and Vault.
| Endpoint | Scope | Limit |
|---|---|---|
| Authorization request | per redirect target and session | 30 per minute |
| Authorization code redemption | per code | 3 attempts |
| Token refresh | per user | 20 per 15 minutes |
Authorization Codes Are Single-Use
An authorization code can be redeemed exactly once. If redemption fails(expired code or mismatched state) the code is invalidated and cannot be retried. Your application should not attempt to redeem a failed code repeatedly. The correct behavior is to restart the flow from the authorization request.
Codes expire shortly after issuance. If your backend exchanges the code for tokens, do so promptly after receiving the callback.
Refresh Tokens
The refresh endpoint is called by your backend, automatically, on behalf of users. It is limited to twenty requests per fifteen minutes per user. Given the fact that the access_token is valid for 15 minutes, you should never trip this limit.
The limit exists to catch malfunctioning clients: an application stuck in a refresh retry loop consumes its own budget. Handle 429 on this endpoint specially:
- Do not refresh again immediately.
- Pause token rotation for the duration in the response message.
- Resume normal rotation afterwards.
An unhandled 429 here is the single most common cause of broken user sessions reported by integrators, because the refresh call is invisible to the user. Their session simply stops working. Handle it.
API v1 Limits
Applications calling API v1 endpoints are limited per client(your application’s registration) and per user whose data is acted on.
| Endpoint | Scope | Limit |
|---|---|---|
| Any API v1 endpoint | per application | 50 per minute |
| User data endpoints | per user | 100 per minute |
The per-application limit is the binding one for typical usage: fifty requests per minute sustained, per client, across all your users. Requests made on behalf of different users do not share the user budget, but they all count against your application’s budget.
For most applications this is ample headroom. If your application polls Vault, for example, syncing deleted users through the purge endpoint, poll at intervals of ten seconds or greater, and back off if you observe 429 responses.
Best Practices
Honor the block duration. The 429 message states how long the block lasts. Waiting that duration, then retrying once, is always sufficient.
Persist your own backoff. When your backend receives a 429, record the event and suppress retries for that user or endpoint for the indicated duration. A single state variable prevents almost all repeat offenses.
Never auto-retry authentication. Login, password reset, and registration are user-paced actions. Never wrap them in automatic retry loops. A loop that cannot succeed burns the user’s budget and can lock their account for the block duration.
Spread scheduled work. If you run periodic background jobs against Vault(purges, syncs, audits) stagger them rather than running them all at the top of every minute. Bursts of simultaneous requests from one application are exactly what the per-client limit is watching for. Vault store only user related data. It should not be involved into any system routine under any circumstances
Monitor your 429 rate. A steady trickle of 429s from your integration means your usage pattern is brushing against a limit — adjust before it becomes an outage. Occasional single 429s during a user’s manual retries
are normal and expected.
Frequently Asked Questions
A user reports being locked out. What happened?
Someone(possibly the user, possibly an attacker) made repeated failed login attempts for that account. The block clears automatically after the indicated duration. There is no way to lift it manually from your side, by
design: a lockout that an application could clear on demand would be a lockout an attacker could clear on demand too.
Why did all my users get 429s at the same time?
Your application’s per-client budget was consumed by a burst, usually a background job, a deploy that restarted polling loops, or an error path triggering retries. Inspect what happened in the minutes before the block started. Adjust per the best practices above.
Do limits apply to the sandbox/test environment?
Limits are enforced in all environments. Testing an integration should never approach them, if your test suite does, it will also violate the same limits in production.
Where can I ask for higher limits?
At this moment higher throughput are not available with plans. The limits are the same for everyone.
Note: We will not refrain from adding this options for paid plans in the future