Two unofficial engines trade account risk for memory
OpenWA turns WhatsApp sessions into an HTTP API with a dashboard, webhooks, API keys, group operations, labels, media, and delivery events. It supports multiple sessions in one instance and lets operators choose SQLite or PostgreSQL, optional Redis, and local or S3-compatible storage. The default whatsapp-web.js engine controls a headless Chromium session. Baileys speaks the multi-device protocol directly and avoids the browser.
Neither engine is Meta's official business API. The README says whatsapp-web.js has a lower fingerprinting risk but uses about 300 to 500 MB of RAM per session, while Baileys uses about 30 to 80 MB and carries higher risk. Those are project-stated ranges, not our measurements. A dedicated number, conservative sending, opted-in recipients, and a fallback channel are operating requirements. They do not eliminate restriction or ban risk.
API success can still mean the recipient saw nothing
Issue 830 documents first messages to brand-new contacts that return a message ID and successful HTTP status but never arrive. The project attributes the behavior to WhatsApp's server-side trust policy after OpenWA hands off the message. Existing conversations work in the reported cases, and delivery may begin once the recipient writes first. OpenWA cannot make an unofficial client override that policy.
This breaks a common assumption in automation: a 200 response is acceptance by the gateway, not proof of delivery to the phone. Workflows should wait for delivery events, expose an unresolved state, and switch to SMS, email, or the official API when the message matters. Cold outreach is a poor fit. The README says regulated, healthcare, finance, large commercial, and EU or EEA compliance-sensitive deployments should treat OpenWA as unapproved.
What happened when we ran it
Our sandbox installed 1,293 npm packages in 59 seconds and consumed 913 MB on disk. The build succeeded in 20 seconds. Jest then reported 5,897 passed, 0 failed, and 6 skipped out of 5,903 in 77 seconds. We tested commit ac4cda9 with Node.js 22, 3 CPUs, 8 GB of RAM, and no secrets. npm audit found 5 known vulnerabilities, all high severity.
The checkout contained 1,581 files and about 219,509 lines of source. We found 9 CI workflow files, a Dockerfile, a compose file, and a tests directory. The clean build and large passing suite are meaningful for the application code. Our sandbox did not link a phone, start Chromium, connect to WhatsApp, send a message, receive media, restore a session, or test a platform ban. The 77-second suite does not verify live protocol compatibility.
Docker is straightforward, while state needs deliberate care
The recommended development path starts a bundled API and dashboard on port 2785. Production Compose profiles can add PostgreSQL, Redis, and MinIO. The Node process drops privileges after the entrypoint fixes volume ownership. A Docker socket proxy limits enabled API paths, but the README warns that POST access can still make a compromised application container equivalent to host root because container-create payloads are not finely constrained. Disable built-in datastore orchestration if that gateway is unnecessary.
Persistent credentials and session state are the harder part. Operators need backups, secret rotation, TLS, a reverse proxy, webhook HMAC checking, and monitoring for relink-required states. Version 0.23.3 fixed duplicate session auto-start, stale QR behavior, and several Baileys pairing races. The release also warns that forcing Bull Board's obliterate action can delete active jobs without recording their final delivery failures. Administrative convenience can erase audit evidence.
Inbound media can reach a webhook without media
Issue 1466 reports that version 0.23.0 sometimes emitted an inbound image or video webhook with the correct message type but no media object after whatsapp-web.js failed to download the attachment. The reporter ran 4 sessions on a host where the container used about 5.9 of 7.6 GiB and logged a Puppeteer-side error. Those conditions do not establish one cause, but the payload was incomplete.
Consumers should treat type and content as separate fields. If a media event lacks media bytes or an explicit omission reason, queue it for recovery through another endpoint and alert after a bounded retry. Never acknowledge a customer document as processed merely because the webhook arrived. OpenWA's storage backend handles backup and migration; the README says message media is returned inline and is not automatically persisted there. Downstream storage is your responsibility.
MCP starts with 25 read-only tools for good reason
Setting MCP_ENABLED=true adds a Streamable HTTP endpoint to the same server. The default surface has 25 read-only tools for sessions, messages, contacts, groups, webhooks, labels, and automation rules. Disabling read-only mode expands it to 51 tools, including sends, replies, and group changes. Every call uses OpenWA's API key roles and session scoping.
The safest agent key is non-admin, limited to one session, and subject to a separate rate limit. The README rejects keys with IP allow-lists over MCP because the transport has no genuine client IP. It also says not to expose the endpoint publicly without an authentication proxy; OAuth 2.1 is not implemented. An agent that can read chats already handles sensitive data. An agent that can send creates financial, privacy, and account-reputation risk, so read-only should remain the default.
August releases are active, while Meta sets the ceiling
GitHub showed 13,225 stars, 11 combined issues and pull requests, and a last push on August 24, 2026. Version 0.23.3 was released that day, with new pull requests active on August 26. The queue includes media delivery, older CPU support, and role customization. This is a maintained codebase, and the 5,897 passing tests support that view.
Maintenance cannot control WhatsApp's device-linking and anti-abuse changes. Issue 560 reports a phased passkey requirement that blocked both QR and pairing-code flows for one account across both engines. The right adoption question is whether the convenience of a self-hosted unofficial gateway outweighs that platform dependency. For personal and internal automation on a disposable number, it may. For an order, login, or regulated conversation, the official API is the responsible choice.