API Rate Limits by Plan

AliasFleet limits API requests per minute by plan: Free allows 50, Pro allows 100, and Business allows 200, measured over a rolling 60-second window per account. Separate per-endpoint limits also apply, and every limit breach returns HTTP 429 with a Retry-After header. This page lists the per-plan allowances, the per-endpoint limits, the error response, and the retry steps.

Rate limits by plan#

The general allowance is measured over a rolling 60-second window and resets every 60 seconds. The limit applies per account, not per device, so requests from three open tabs on the same account count toward the same allowance. An upgrade raises the allowance.

Limits by endpoint group#

The API reference states separate limits for each endpoint group, evaluated per client or API key with sliding-window limiters. These limits apply in addition to the per-plan allowance. A request must pass both the plan allowance for the account and the limit for its endpoint group. The API reference states the standard-endpoint limit as 60 requests per minute, while the plan allowances are 50 for Free, 100 for Pro and 200 for Business. Both figures are sourced, and both limits apply to each request.

The endpoint-group limits do not vary by plan in any source. The API reference states them as fixed values per client or API key. The full endpoint reference, including scopes, is in the API Index.

429 error response#

When the request rate passes the allowance, the server answers further requests with HTTP 429 Too Many Requests until the window resets. The response has the form below, as stated in the API Index:

HTTP/1.1 429 Too Many RequestsRetry-After: 12Content-Type: application/json{  "error": "Too Many Requests",  "code": "RATE_LIMIT_EXCEEDED"}

The Retry-After header states how many seconds to wait before the next request. In the dashboard, the same block appears as a "Too many requests" message stating the remaining wait.

Handling a 429 response in an integration#

1. Read the Retry-After header. Every 429 response includes it. The integration waits at least the stated number of seconds before the next request.
2. Use exponential backoff. After each 429, the delay before the next attempt doubles (for example 1, 2, 4, then 8 seconds), up to a maximum. A small random jitter keeps parallel workers from retrying in lockstep.
3. Cap retry attempts. A maximum number of retries per operation keeps a runaway loop from holding the connection open and triggering longer blocks.
4. Reduce the request rate at the source. Batching operations where the API allows it, caching read-heavy responses, and polling on longer intervals lower the rate. Alias creation stays under 10 per minute; Quick-Send stays under 5 per minute.
5. Avoid adding parallel workers. Adding parallel workers raises the request rate and extends the block, so it does not work around a 429.
6. Upgrade only when the general allowance is the constraint. A plan upgrade raises the per-minute allowance to 100 on Pro or 200 on Business. It does not raise the per-endpoint limits in the table above or the sensitive-action limits below.

Checking whether a block has cleared#

1. Close extra tabs and pause polling. Scripts, extensions and other tabs that send requests to AliasFleet stop.
2. Wait without retrying. The wait is 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, a single page reload resumes the session at a normal pace.
4. Confirm normal responses return. Pages loading and actions succeeding show the block has cleared. A 429 error returning at once shows requests are still being sent from somewhere on the account.

Limits on sensitive actions#

Sensitive actions have separate limits that apply across all plans. A plan upgrade does not raise these limits, because they slow automated guessing 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. A fuller description of credential-guessing attacks is in How Credential Stuffing Works.

Requests outside the limit#

Email forwarding is server-side infrastructure and is unaffected by rate limits, so aliases keep forwarding while an API block is active. Static page navigation also issues few requests.

Repeated 429 errors#

When the error persists after the wait and no request is being sent from the account, a support ticket is the route for investigation. The detailed troubleshooting steps for each symptom are in Too Many Requests Error.

See also: Rate Limiting · Too Many Requests Error · API Index · Upgrading to Pro · Plan and Usage Limits