Description
Wiring your own system to send order notifications, one-time codes or support replies over WhatsApp usually means Meta's official Cloud API (per-message billing and an approval process) or a third-party gateway (monthly subscription, and every message passes through their servers). OpenWA offers a third path: run the HTTP gateway yourself, with a standard REST interface and webhooks in front and your own WhatsApp number behind, and nothing leaving your server. One Docker command brings it up, along with a React dashboard for sessions, API keys and webhooks.
The architecture is pluggable: SQLite or PostgreSQL, Redis cache on or off, backups to local disk or S3 — all selected by configuration rather than code changes. One instance runs several WhatsApp sessions at once, and API keys can be scoped to specific sessions. Messages, media, groups, labels and channels all have endpoints, with Swagger docs and n8n community nodes alongside.
The risks are something the author documents plainly, and they are worth reading before you commit. This is not an official interface — it drives reverse-engineered clients (whatsapp-web.js and Baileys), so the risk of a number being restricted or banned is never zero, and no amount of code quality removes it. The README is explicit: do not connect your primary personal or business number, use a dedicated one you can afford to lose; warm a new number up over several days by behaving like a normal user; and never cold-blast numbers that have never messaged you, which is the most reliable way to get restricted. The engine trade-off is documented too — whatsapp-web.js drives a real headless Chromium and looks like genuine traffic (lower risk, 300–500 MB RAM per session), while Baileys speaks the multi-device protocol directly (30–80 MB, but easier to fingerprint).
The author also states outright that for healthcare, finance, large-scale commercial messaging, or anything touching EU users under GDPR/DMA, you should use Meta's official Cloud API instead. OpenWA is aimed at personal projects, internal tooling and learning. MIT licensed.
REST API and webhooks: a full HTTP interface for sending and receiving, with HMAC-signed webhook events and optional pre-dispatch filtering so you are not flooded with callbacks you do not need.
Multiple concurrent sessions: one instance hosts several WhatsApp accounts independently, which suits serving multiple business lines or clients from a single machine.
Web dashboard: a React interface for QR pairing, API keys, webhook configuration and delivery-failure records, rather than doing everything from a terminal.
Session-scoped keys: operator and viewer keys can be restricted to selected sessions, with requests naming another session returning 401; leaving the selection empty grants access to every session, including ones created later.
Pluggable backends: SQLite or PostgreSQL, optional Redis cache, and local or S3/MinIO backup and migration storage, switched by configuration.
Full messaging surface: text, images, video, documents and audio, emoji reactions, message editing with message.edited events on both engines, bulk sending, and delivery and read receipts.
Groups and channels: create groups, manage members, join by invite code and configure settings, plus WhatsApp Channels and chat label management.
Rate limiting and access control: a configurable rate limiter the project explicitly recommends leaving on, CIDR whitelisting for source IPs, and per-session proxy configuration.
Audit logging: an audit trail across API key, session, integration-instance and infrastructure admin operations for tracing who changed what.
Plugins and integrations: official sandboxed plugins for Chatwoot and Typebot, n8n community nodes, and third-party adapters such as ioBroker.
Docker deployment: production-ready Docker configuration with non-root containers, a Docker socket proxy narrowing privileges, and Kubernetes-ready health probes.
The architecture is pluggable: SQLite or PostgreSQL, Redis cache on or off, backups to local disk or S3 — all selected by configuration rather than code changes. One instance runs several WhatsApp sessions at once, and API keys can be scoped to specific sessions. Messages, media, groups, labels and channels all have endpoints, with Swagger docs and n8n community nodes alongside.
The risks are something the author documents plainly, and they are worth reading before you commit. This is not an official interface — it drives reverse-engineered clients (whatsapp-web.js and Baileys), so the risk of a number being restricted or banned is never zero, and no amount of code quality removes it. The README is explicit: do not connect your primary personal or business number, use a dedicated one you can afford to lose; warm a new number up over several days by behaving like a normal user; and never cold-blast numbers that have never messaged you, which is the most reliable way to get restricted. The engine trade-off is documented too — whatsapp-web.js drives a real headless Chromium and looks like genuine traffic (lower risk, 300–500 MB RAM per session), while Baileys speaks the multi-device protocol directly (30–80 MB, but easier to fingerprint).
The author also states outright that for healthcare, finance, large-scale commercial messaging, or anything touching EU users under GDPR/DMA, you should use Meta's official Cloud API instead. OpenWA is aimed at personal projects, internal tooling and learning. MIT licensed.
Features
REST API and webhooks: a full HTTP interface for sending and receiving, with HMAC-signed webhook events and optional pre-dispatch filtering so you are not flooded with callbacks you do not need.
Multiple concurrent sessions: one instance hosts several WhatsApp accounts independently, which suits serving multiple business lines or clients from a single machine.
Web dashboard: a React interface for QR pairing, API keys, webhook configuration and delivery-failure records, rather than doing everything from a terminal.
Session-scoped keys: operator and viewer keys can be restricted to selected sessions, with requests naming another session returning 401; leaving the selection empty grants access to every session, including ones created later.
Pluggable backends: SQLite or PostgreSQL, optional Redis cache, and local or S3/MinIO backup and migration storage, switched by configuration.
Full messaging surface: text, images, video, documents and audio, emoji reactions, message editing with message.edited events on both engines, bulk sending, and delivery and read receipts.
Groups and channels: create groups, manage members, join by invite code and configure settings, plus WhatsApp Channels and chat label management.
Rate limiting and access control: a configurable rate limiter the project explicitly recommends leaving on, CIDR whitelisting for source IPs, and per-session proxy configuration.
Audit logging: an audit trail across API key, session, integration-instance and infrastructure admin operations for tracing who changed what.
Plugins and integrations: official sandboxed plugins for Chatwoot and Typebot, n8n community nodes, and third-party adapters such as ioBroker.
Docker deployment: production-ready Docker configuration with non-root containers, a Docker socket proxy narrowing privileges, and Kubernetes-ready health probes.
