Anti-Ban Controls
The real per-session send-pacing controls in WaSphere — the default 4–12s human-like delay, the rolling per-minute cap, read and receive toggles, proxies, and an honest account of what they can and cannot prevent.
Anti-Ban Controls
Baileys sessions connect to WhatsApp over the unofficial web protocol. WhatsApp actively detects and bans automated accounts, and the strongest signal it has is behaviour that no human could produce — hundreds of messages a minute, zero gap between sends, perfectly uniform timing.
WaSphere's anti-ban controls exist to make an automated session's outbound traffic look unremarkable. They are per-session, applied in-process by the WA Server, and take effect immediately without restarting the session.
None of this makes a ban impossible. Send pacing reduces one category of risk. It does nothing about unsolicited messaging, recipients pressing Block or Report, a brand-new number blasting strangers, or WhatsApp simply changing its detection. If you cannot tolerate a ban, use the Meta Cloud API provider — the official API, where this entire class of risk does not exist.
The controls
Every session carries this configuration:
| Setting | Default | What it does |
|---|---|---|
random_delay_min_ms | 4000 | Lower bound of the random pause before each outgoing message |
random_delay_max_ms | 12000 | Upper bound. The actual pause is uniformly random in [min, max] |
max_messages_per_minute | 0 | Cap on outgoing messages per rolling 60 seconds. 0 = unlimited |
auto_read_on_receive | false | Mark inbound messages read as soon as they arrive |
receive_enabled | true | When false, the session emits no inbound message events |
In the dashboard these live on Sessions, where the Anti-Ban controls are always visible.
The human-like delay
New sessions default to a 4–12 second random pause before every outgoing message. That is deliberately slow — roughly the pace of a person actually typing and thinking, not a script.
The delay is randomised on every send rather than fixed, because a constant interval is itself a machine signature. Setting both bounds to 0 disables the delay entirely; random_delay_max_ms must be greater than or equal to random_delay_min_ms, and each accepts up to 300000 ms (5 minutes).
The 4–12s default was raised in v1.2. Sessions created before then keep whatever values they were configured with — check them if you are upgrading.
The per-minute cap
max_messages_per_minute is an opt-in throughput ceiling, off by default (0). When set, the WA Server keeps a rolling 60-second window of send timestamps for the session. If the window is already full, the send waits until the oldest entry ages out of the window, then proceeds.
This means the cap paces your sends — it does not reject them. A message sent over the limit is delayed, never dropped and never returned as an error. A burst of API calls simply drains at the rate you configured.
Note that this ceiling composes with the random delay: with a 4–12s delay you already average around 7–8 messages per minute, so a cap only bites if you have lowered the delay.
Read and receive toggles
auto_read_on_receive marks inbound messages as read the moment they arrive. It is useful for a pure bot session where nobody is reading a thread; leave it false for human-operated numbers so agents can see what is genuinely unread in the Inbox.
receive_enabled set to false stops the session emitting inbound events at all — appropriate for a send-only notification number, and a straightforward way to cut webhook noise.
Configuring a session
Set the values at creation time:
curl -X POST https://api.yourdomain.com/workspaces/{workspaceId}/proxy/api/sessions \
-H "Authorization: Bearer wsk_your_key" \
-H "Content-Type: application/json" \
-d '{
"id": "support",
"random_delay_min_ms": 4000,
"random_delay_max_ms": 12000,
"max_messages_per_minute": 20,
"auto_read_on_receive": false,
"receive_enabled": true
}'The same field names are accepted when patching an existing session's configuration, and changes apply to subsequent sends without a reconnect.
Per-session proxies
Each session can route its WhatsApp connection through its own HTTP, HTTPS, or SOCKS5 proxy, so multiple numbers do not all originate from one server IP:
{ "id": "support", "proxy": "socks5://10.0.0.5:1080" }Credentials embedded in the URL are rejected. The proxy is fixed at creation — to change it, delete and re-create the session.
What actually reduces risk
Pacing is the part WaSphere can control. The rest is on how you use it:
- Message people who asked to hear from you. Opt-in is the single biggest factor. Blocks and reports weigh far more heavily than timing.
- Warm a new number up. A number linked an hour ago sending a thousand messages is the classic ban pattern. Start small and grow over days.
- Keep the default delay unless you have a specific reason to lower it. Faster is riskier, always.
- Set a per-minute cap on bulk sends, and lower it further for marketing-style traffic than for transactional replies.
- Separate concerns across numbers — a
supportnumber a human answers behaves very differently from anotificationsnumber, and one getting banned should not take the other with it. - Give people a way out. An easy opt-out prevents the reports that drive bans.
For high-volume marketing to people who did not explicitly opt in, no amount of delay tuning will save the account. That workload belongs on the Meta Cloud API with approved templates, where the rules are enforced up front instead of by a ban.
Related
- Sessions — lifecycle, persistence, and reconnection
- Meta Cloud API — the official-API alternative
- Send messages — the send endpoints these settings pace