Handle WhatsApp messages via API on your own server
Once you link a phone number and scan a QR code, WhatsApp chat rooms open up to HTTP requests. Based on unofficial clients rather than Meta's official API, it allows you to send and receive messages without license fees or feature restrictions. This serves as a gateway for developers to directly control message flow on their own infrastructure.
Plugin architecture and session control
You can swap the database and media storage using only configuration files, changing the environment without modifying code. You can choose SQLite or PostgreSQL as the data store, and local disk or S3-compatible storage as the media backend. A single instance can run multiple WhatsApp sessions simultaneously, issuing independent API keys for each session to granularize access permissions. In particular, you can restrict key access scope by session or specific chat room, isolating AI agents or third-party integrations so they only process designated conversations within a shared account.
Essential checks for account safety
Because this tool uses unofficial clients like whatsapp-web.js and baileys instead of Meta's official Cloud API, the risk of account restrictions or bans always exists. Do not link your main personal or business number; you must use a dedicated number that you can afford to lose. whatsapp-web.js runs headless Chromium to mimic real web traffic, lowering the risk of being blocked, but it consumes 300–500MB of RAM per session. In contrast, baileys uses less memory, at 30–80MB, but is vulnerable to protocol fingerprint analysis, resulting in a higher risk of being blocked. If account safety is the top priority, choose whatsapp-web.js when you have memory headroom; if you need density and can accept the risk, choose baileys.
Guidelines for stable operation
It is recommended to warm up new numbers by behaving like normal users for several days. Sending messages to large numbers of unknown contacts from the start is most likely to trigger restriction measures. You can enable the SEND_PACING_ENABLED option to set daily sending limits and new conversation restrictions that increase according to the session's age. It is safest to send only to recipients who already expect a message, such as opt-in targets for OTP transmission or order updates. For flows critical to authentication or revenue, you should maintain SMS, email, or the official API as alternative routes.
Docker-based deployment and security structure
You can build a production environment with a single Docker Compose file, optionally running additional services like PostgreSQL, Redis, and MinIO based on profiles. In the production image, the Node.js process does not run with root privileges; permissions are safely lowered through dumb-init and gosu. The Docker socket is not directly exposed; instead, a dedicated proxy sidecar allows only the necessary container orchestration tasks. The dashboard is bundled within the API image and served on the same port; when using TLS or exposing publicly, you must place a reverse proxy like nginx or Caddy in front.
Suitable use cases and limitations
It is suitable for personal projects, internal tools, automation hobbies, and learning purposes, but in environments requiring regulatory compliance, such as healthcare, finance, or large-scale commercial messaging, you must use the official API. Due to WhatsApp server-side policies, the first message sent to a new contact may not be delivered, or account restrictions may be irreversible; this is a platform policy, not a defect of OpenWA. Some accounts may have an additional passkey step that prevents linking new devices, so it is best not to log out or reconnect working sessions. This tool is not a replacement for the official API, but an independent solution for developers who want control.