A "Too many requests" error, shown as HTTP 429, means the account or IP address has exceeded its per-minute request limit. General blocks clear within 60 seconds. Login page blocks, caused by repeated failed sign-in attempts, last up to 10 minutes. This page covers the limits by plan, the common causes of each block, and the steps that clear them.
These steps require an AliasFleet account. The integration section also requires an API key with integration access.
Meaning of the 429 error#
When the request rate passes the account's per-minute allowance, the server answers every further request with HTTP 429 Too Many Requests until the time window resets. The error text normally reads "Too many requests" and states the remaining wait. The account is not flagged or suspended.
Per-minute allowances by plan:
| Plan | Requests per minute |
|---|---|
| Free | 50 |
| Pro | 100 |
| Business | 200 |
The allowances cover all API use on the account, including the dashboard's own background calls. The full policy, including why the limits exist and how endpoints are counted, is in Rate Limiting.
Block duration#
General API blocks clear within 60 seconds. The limit is measured over a rolling minute, so the block lifts as soon as the request rate falls back inside the allowance.
Login page blocks last up to 10 minutes. They are triggered by repeated failed sign-in attempts from the same IP address and act as a guard against brute-force password guessing. The error message states the exact remaining wait.
If the error continues past these windows, requests are still being sent from somewhere. The usual sources are browser extensions that poll, other tabs with background sync running, or scripts retrying in a tight loop.
Common triggers#
Rate limiting reacts to volume, not to intent. The common triggers are:
- Rapid page refreshes, which fire several background API calls at once.
- Multiple open tabs running background sync at the same time.
- Scripts, automations, or integrations that issue requests faster than the per-minute allowance.
- Browser extensions that poll the dashboard or API on a short interval.
- Retry loops that resend a failed request immediately instead of waiting.
Normal usage#
Ordinary use stays far below the limits. Browsing aliases, creating or editing aliases, sending email, checking activity, and using the dashboard in a single tab are all normal use. One page load issues only a handful of requests, so normal sessions do not approach 50 requests per minute even on the Free plan.
Clearing a dashboard block#
- Stop all requests. Close extra tabs with AliasFleet open. Pause scripts or extensions that poll the API.
- Wait 60 seconds. Do not reload or retry during the wait. Each new request is rejected as well, so retrying only lengthens the perceived delay.
- Reload once. After the minute has passed, reload the page a single time and continue at a normal pace.
- Remove the cause. If a browser extension or a retry loop caused the block, disable the extension or fix the loop before continuing.
Clearing a login page block#
- Stop attempting to sign in. Further attempts are rejected and do not shorten the block.
- Wait up to 10 minutes. The block is measured from the last failed attempt, so the wait must be uninterrupted.
- Sign in once with the correct credentials. After the wait, enter the email address and password a single time. Do not submit repeatedly.
- Reset the password instead of guessing. If the password is uncertain, use the password reset flow rather than retrying guesses. Repeated guessing extends the block.
- Check for automated attempts. If the block was not caused by manual attempts, check whether a password manager, script, or another device is submitting credentials.
The login block slows automated password guessing. A fuller description of credential-guessing attacks is in How Credential Stuffing Works.
Handling 429 responses in integrations#
- Read the
Retry-Afterheader. Every 429 response includes aRetry-Afterheader stating how many seconds to wait before the next request. Wait at least that long. - Implement exponential backoff. After each 429, double the delay before the next attempt (for example 1, 2, 4, then 8 seconds), up to a maximum. Add a small random jitter so parallel workers do not retry in lockstep.
- Cap retry attempts. Set a maximum number of retries per operation. A bounded retry count keeps a runaway loop from holding the connection open and triggering longer blocks.
- Reduce the request rate at the source. Batch operations where the API allows it, cache read-heavy responses, and poll on longer intervals instead of short continuous loops.
- Upgrade the plan if the limits are hit regularly. The per-minute allowance rises with the plan: 50 on Free, 100 on Pro, 200 on Business. API Rate Limits by Plan lists the current allowances per tier.
Do not add parallel workers or faster retry intervals to work around a 429. Higher concurrency raises the request rate and extends the block.
Symptom and fix matrix#
| Symptom | Likely cause | Fix |
|---|---|---|
| 429 in the dashboard after rapid refreshes | Rolling per-minute limit exceeded | Wait 60 seconds, reload once |
| 429 on the login page | Repeated failed sign-in attempts from the IP | Wait up to 10 minutes, sign in once |
| 429 from a script or integration | Requests above the plan allowance | Implement backoff, honour Retry-After |
| 429 that never clears | Requests still being sent | Close tabs, disable extensions, stop scripts |
| 429 on every action after upgrade | Requests still above the new allowance | Slow the rate; the 60-second block still applies |
Full rate limit policy#
The reference for the full policy, including the purpose of the limits and how each endpoint is counted, is Rate Limiting. Plan-specific allowances are in API Rate Limits by Plan.
If the error persists after waiting and nothing on the account is issuing requests, open a support ticket so the cause can be investigated.