Account throttled or banned: the common triggers for relay service risk controls

First, the distinction that matters

"There is a problem with my account" covers three different situations, and they need different responses:

Most people treat all three as "banned" and either panic or argue. Diagnosing which one you have is the first step.

Trigger one: volume that looks abnormal

What it looks like: 429s and rate limiting appearing as soon as your traffic grows, often correlated with a specific hour.

Why: the relay service's own upstream capacity is finite, and low-cost tiers are usually capped hard. Your growth looks to them exactly like abuse.

What to do: check whether the cap is on the tier you bought (most service pages state it), and whether the pattern is concurrency-shaped or total-volume-shaped. Concurrency caps are worked around by queuing your requests; total-volume caps mean you need a higher tier or a second service.

Trigger two: shared IPs and shared channels

What it looks like: you did nothing differently and suddenly get limited, along with a burst of other users.

Why: a lot of low-cost supply comes from resold subscription quota or reverse-engineered endpoints. Those channels are shared, and when the vendor's risk controls fire, everyone on the channel is affected at once — including you, who did nothing.

What to do: this is the most common structural cause, and it is the reason we keep saying the cheap tier's real cost is the risk of the channel disappearing. Ask the service which upstreams your traffic uses. An operator that can answer is also an operator that can route you elsewhere.

Trigger three: patterns that look automated to the fraud detector

What it looks like: limiting that starts after you deploy a batch job.

Why: identical prompts at a fixed interval, no jitter, requests exactly on the minute — these are indistinguishable from scraping or credential abuse from the outside.

What to do: add jitter, vary the interval, and stay well below the documented concurrency cap rather than at it. Rate limiting exists to protect the service; working with it is cheaper than fighting it.

Trigger four: content that trips a policy filter

What it looks like: 403s on specific requests while others go through.

Why: most vendors apply content policies upstream. The relay is usually just passing the vendor's rejection back.

What to do: check whether the same request goes through on a different model or a different provider. If it does, the filter is upstream and no amount of complaining to the relay will change it.

Trigger five: payment and identity checks

What it looks like: the account works, then stops, with a message about verification.

Why: some services, especially larger ones, periodically re-verify accounts or flag accounts funded through channels they consider risky.

What to do: respond to the request promptly with what they ask for. Ignoring it turns a suspension into a ban.

What to do the moment it happens

1. Read the actual error and the status code. 401, 403, 429 and 500 all mean different things and are dealt with differently.
2. Test with a minimal request. A one-line prompt removes your own code from the equation.
3. Test a second model on the same key. If that works, the problem is model-specific rather than account-wide.
4. Test a second key if you have one. This separates "my account" from "the service".
5. Contact support with the evidence — timestamps, request IDs, status codes. This turns a vague complaint into something they can act on, and gets resolved far faster.
6. Switch to your backup route while waiting. Do not let an account dispute become a service outage.

Preventing it in the first place

• Do not run at the cap. If your tier allows five concurrent requests, run three.
• Add jitter to batch jobs.
• Keep credentials in configuration, so rotating to a backup is an environment variable change and not a deploy.
• Do not concentrate volume on one account. If you have several workloads, consider separate keys so a limit on one does not take everything down.
• Keep some balance on a second service at all times. The moment you need it is the moment you cannot wait for a top-up to clear.

Related reading

• A relay service starts erroring or slowing down: how to tell whose problem it is (guides)
• Six signals that a relay service is about to disappear (guides)
• Six common tricks in cheap relay services (guides)