Send without getting banned

OpenWA is unofficial. It drives WhatsApp through reverse-engineered clients — the whatsapp-web.js and baileys engines — not Meta's official Cloud API, so every number you connect carries a non-zero risk of restriction or ban. Connect a dedicated number you can afford to lose, never your primary personal or business number — and if you run OpenWA for paying clients, pass the same guidance on to them.

No guardrail makes the risk zero

WhatsApp's anti-abuse systems actively look for unofficial automation. The practices below materially reduce the chance of the account being flagged; they cannot eliminate it.

Pick an engine: ban risk vs resource cost

The two engines sit at opposite ends of the safety–density trade-off:

Engine	Ban-risk profile	Resource cost
whatsapp-web.js	Lower — drives a real headless Chromium that looks like genuine WhatsApp Web traffic.	High RAM (~300–500 MB per session).
baileys	Higher — speaks the multi-device WebSocket protocol directly and is easier for WhatsApp to fingerprint.	Low RAM (~30–80 MB per session).

If account safety is your top priority and you can afford the memory, set ENGINE_TYPE=whatsapp-web.js. If you need session density and accept the trade-off, use baileys. See Configuration.

Follow the safe-sending guardrails

1. Warm up fresh numbers. For the first several days, behave like a normal human user: scan the QR, exchange a handful of messages with saved contacts, join a group or two, set a profile photo. Do not blast on day one.
2. Never cold-blast strangers. Sending the first-ever message to a large batch of numbers that have never messaged you is the single most reliable way to get restricted — on either engine.
3. Rate-limit your sends. OpenWA ships a configurable rate limiter, controlled by the RATE_LIMIT_* environment variables — see Configuration. A few messages per minute per session is sustainable; thousands in an hour is not.
4. Message only opted-in recipients. The safest workloads are replies and alerts to people who already expect to hear from you: OTPs for your own users, order updates, support replies.
5. Keep a fallback channel. For anything auth-critical or revenue-critical, keep an SMS, email, or official Cloud API path. Do not bet a login flow solely on an unofficial client.
6. Mind the hosting IP. Datacenter IPs are flagged more aggressively than residential ones. A residential proxy per session — set proxyUrl and proxyType when you create the session, see Sessions — can help; it is not a license to spam.

Know what is WhatsApp policy, not an OpenWA bug

Two behaviors look like OpenWA defects but are server-side WhatsApp policy:

• A first message to a brand-new contact sometimes never arrives. The API returns success because the message leaves OpenWA, but WhatsApp's server-side reach-out and trust policy drops it at delivery. OpenWA tracks this in core issue #830.
• A banned account cannot be unbanned by OpenWA. If WhatsApp disables a number, appeal through WhatsApp's channels — OpenWA has no lever to pull.

Use the official API for regulated workloads

For any deployment where legal or regulatory compliance matters — healthcare, finance, large-scale commercial messaging, anything touching end users in the EU/EEA under DMA/GDPR — treat OpenWA as not approved and use Meta's official WhatsApp Business Cloud API. OpenWA fits personal projects, internal tooling, and automation; it is not a drop-in replacement for the official API in regulated environments.

Next steps

• Sending messages — every send route, including paced bulk broadcasts.
• Sessions — per-session proxy settings and the full lifecycle.
• Configuration — ENGINE_TYPE and the RATE_LIMIT_* variables.