Rate Limiting and Account Protection

This page states the rate limits that apply to an AliasFleet account: the per-minute allowance for each plan, the separate limits on login, password reset, sign-up, and verification resends, what the 429 Too Many Requests response means, and the steps that restore access and prevent repeat blocks.

What is rate limiting?#

Rate limiting is a cap on how many requests an account may make in a set time window. Any request that loads or changes data counts toward the cap: loading the alias list, creating or editing an alias, fetching sessions, loading destinations, checking activity, and checking billing or usage data. The cap stops one account, script, or automated guessing attempt from consuming shared capacity at the expense of other accounts.

Limits are measured per account, not per device. Requests from three open tabs on the same account all count toward the same allowance. Email forwarding runs on the server and is not subject to API rate limits, so aliases keep forwarding while an API block is active.

What are the rate limits by plan?#

The general allowance is measured over a rolling 60-second window and resets every 60 seconds.

Ordinary use stays well below these allowances. Browsing aliases, managing destinations, and checking activity in a single tab issues only a handful of requests per page load, so a normal session does not approach 50 requests per minute even on the Free plan. The full per-plan detail, including what counts as a request, is in API Rate Limits by Plan.

What limits apply to sensitive actions?#

Sensitive actions have separate limits that apply across all plans. Upgrading the plan does not raise these limits, because they slow automated guessing and abuse rather than metering usage.

The login limit is measured per IP address, not per account, so repeated failed sign-in attempts from one address trigger the block even when the attempts target different accounts. The login block slows automated password guessing. A fuller description of credential-guessing attacks is in How Credential Stuffing Works.

What happens when a limit is reached?#

When the request rate passes the allowance, the server answers further requests with HTTP 429 Too Many Requests until the window resets. The error text normally reads "Too many requests" and states the remaining wait. Every 429 response also includes a Retry-After header stating how many seconds to wait before the next request.

General API blocks clear within 60 seconds, once the request rate falls back inside the allowance. Login blocks last up to 10 minutes, measured from the last failed attempt. Hitting a rate limit is temporary and automatic: the account is not flagged, penalised, or put at risk of suspension for hitting a limit occasionally. The step-by-step fix for each kind of block is in Too Many Requests Error.

How to stay inside the limits#

1. Work in one tab. Extra tabs with AliasFleet open run background sync and add requests to the same per-account allowance.
2. Stop requests during a block. Do not reload or retry while a block is active. Each new request is rejected as well, so retrying only lengthens the perceived delay.
3. Wait out the full window. Wait 60 seconds for a general block, or up to 10 minutes for a login block, before trying again.
4. Honour the Retry-After header in integrations. Wait at least the stated number of seconds before the next request, and increase the delay after each retry so each retry waits longer than the last.
5. Slow 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.
6. Upgrade only when the general allowance is the constraint. A higher plan raises the per-minute allowance to 100 on Pro or 200 on Business. It does not raise the sensitive-action limits in the table above.

How to check whether a block has cleared#

1. Close extra tabs and pause polling. Stop scripts, extensions, and other tabs that send requests to AliasFleet.
2. Wait without retrying. Wait 60 seconds for a general block, or up to 10 minutes for a login block, measured from the last request or failed attempt.
3. Reload once. After the wait, reload the page a single time and continue at a normal pace.
4. Confirm normal responses return. If pages load and actions succeed, the block has cleared. If the 429 error returns at once, requests are still being sent from somewhere on the account.

What if the error keeps returning?#

If the error persists after waiting and nothing on the account is issuing requests, open a support ticket so the cause can be investigated. The detailed troubleshooting steps for each symptom are in Too Many Requests Error.

See also: API Rate Limits by Plan · Too Many Requests Error