OpenWA 是一款免费开源的 WhatsApp API 网关，基于 Node.js、NestJS 与 Docker 构建，支持多会话、Webhook、仪表盘、媒体消息和 n8n 集成，适合开发者在 Linux 服务器上自建可控的客户通知、社群运营与业务消息自动化平台。

🎤 引言：把 WhatsApp 变成可编排的业务接口

如果你做过跨境业务、客户通知、社群运营或售后提醒，大概率会遇到同一个痛点：WhatsApp 是用户每天都在看的沟通入口，但开发者想把它接进自己的系统，却常常被平台限制、商业 API 价格、第三方 SaaS 套餐和数据归属问题卡住。

例如一个独立站团队想在订单付款后自动发 WhatsApp 提醒，客服希望在仪表盘里管理多个账号，运营又想把新消息转到 n8n、CRM 或工单系统。传统做法要么依赖收费平台，要么自己拼接脚本，稳定性、权限控制、日志审计和后续扩展都会变成麻烦。

OpenWA 的定位很直接：它是一个免费开源的 WhatsApp API Gateway，用 HTTP API、Webhook、Dashboard 和 Docker 部署，把 WhatsApp 能力包装成一套可自建、可迁移、可自动化的基础设施。项目当前版本为 0.1.6，采用 MIT 协议，最近一次提交在 2026 年 5 月，仓库显示已有 6.1k Stars，说明它已经受到不少开发者关注。

⭐ 核心功能：REST API、Webhook、多会话一套打通

OpenWA 最核心的能力，是把 WhatsApp 操作抽象成标准 REST API。你可以通过接口创建 Session，启动会话，获取二维码，让手机扫码登录，然后调用发送文本、图片、视频、文档、音频等消息接口。对于业务系统来说，WhatsApp 不再是一个只能人工打开的 App，而是一个可以被后端服务调用的消息通道。

第二个关键点是 Multi-Session。很多团队不是只有一个 WhatsApp 账号：销售线、客服线、活动线、不同地区账号，往往需要并行存在。OpenWA 支持在同一实例上运行多个 WhatsApp Session，每个会话都可以独立管理，适合做多账号通知、分业务线客服或不同项目的消息自动化。

第三个亮点是 Webhook。系统收到消息、会话状态变化、发送状态回执时，可以实时推送到你自己的服务端。比如用户发来关键词，Webhook 进入 n8n，n8n 再调用数据库、AI 总结、CRM 或 Telegram 通知。这样一来，WhatsApp 就从单纯聊天工具，升级成自动化工作流里的触发器。

项目还内置 Web Dashboard。界面用于管理 Session、Webhook、API Key 等配置。对非纯后端用户来说，这个仪表盘很重要：它能减少命令行操作，让账号状态、二维码登录、接口密钥和 Webhook 配置更直观。README 中还明确提供 Swagger 文档，地址为 http://localhost:2785/api/docs，方便开发者边看接口边调试。

🧱 技术架构：NestJS + TypeScript + whatsapp-web.js

OpenWA 的后端基于 Node.js 22 LTS、NestJS 11.x 和 TypeScript 5.x 构建，WhatsApp 引擎使用 whatsapp-web.js。这个技术组合的优点是生态成熟、开发门槛低、部署资源相对轻量，适合 VPS、Docker 主机或内网服务器运行。

它比较有价值的一点是可插拔架构。官方文档明确提到，数据库可以在 SQLite 与 PostgreSQL 之间切换，缓存可以使用 Memory 或 Redis，媒体存储可以走本地文件，也可以扩展到 S3 或 MinIO。这意味着你可以先用 SQLite 快速跑起来，验证流程后再迁移到 PostgreSQL、Redis、对象存储这样的生产组合。

项目的基础设施能力也比较完整：API Key Auth 用于接口鉴权，Rate Limiting 可以限制请求频率，CIDR Whitelisting 可以按 IP 白名单控制访问来源，Audit Logging 用来记录 API 操作。对于消息网关这种容易被滥用的系统来说，这些安全和审计能力不是锦上添花，而是上线前必须考虑的底座。

从部署角度看，OpenWA 原生支持 Docker Compose。API 默认端口是 2785，Dashboard 默认端口是 2886，Swagger 文档在 2785/api/docs。对于辰镭大哥这类喜欢 VPS + Docker + Nginx 反代的环境，它的部署形态非常顺手：容器启动后，宝塔或 Nginx 只需要反代到对应端口，再配好 SSL 和访问控制即可。

📥 安装部署：两个命令先跑起来

如果只是本地体验，官方推荐的开发模式非常简单：

git clone https://github.com/rmyndharis/OpenWA.git
cd OpenWA
docker compose -f docker-compose.dev.yml up -d

启动后可以访问三个入口：Dashboard 是 http://localhost:2886，API 是 http://localhost:2785/api，Swagger 是 http://localhost:2785/api/docs。第一次使用时，通常先进入 Dashboard 或 API 创建 Session，然后扫码登录 WhatsApp。

如果是本地开发，也可以不用 Docker：

git clone https://github.com/rmyndharis/OpenWA.git
cd OpenWA
npm install
npm run dev

生产环境则使用主 docker-compose.yml，并通过 Profile 选择组件。基础模式使用 SQLite 和本地存储，适合个人项目、测试环境或低流量通知；postgres Profile 会启用 PostgreSQL；full Profile 则包含 PostgreSQL、Redis、Dashboard、Traefik 等完整栈。

对实际部署来说，我更建议采用渐进式方案：先用 SQLite + 本地存储跑通扫码、发消息、Webhook；确认业务流程稳定后，再切 PostgreSQL 和 Redis。这样可以避免一开始就被数据库、缓存、对象存储配置拖慢验证速度。

🔌 API 示例：从创建会话到发送消息

OpenWA 的 API 设计比较直观。创建 Session 可以这样调用：

curl -X POST http://localhost:2785/api/sessions \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{"name": "my-bot"}'

启动 Session 并获取二维码：

curl -X POST http://localhost:2785/api/sessions/{sessionId}/start \
  -H "X-API-Key: YOUR_API_KEY"

curl http://localhost:2785/api/sessions/{sessionId}/qr \
  -H "X-API-Key: YOUR_API_KEY"

发送文本消息也很清晰：

curl -X POST http://localhost:2785/api/sessions/{sessionId}/messages/send-text \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{
    "chatId": "[email protected]",
    "text": "Hello from OpenWA!"
  }'

Webhook 则可以把消息事件推送到你的服务端：

curl -X POST http://localhost:2785/api/sessions/{sessionId}/webhooks \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{
    "url": "https://your-server.com/webhook",
    "events": ["message.received", "session.status"],
    "secret": "your-hmac-secret"
  }'

这些接口组合起来后，就可以形成完整自动化链路：用户 WhatsApp 发消息 → OpenWA 接收 → Webhook 推送到 n8n → n8n 判断关键词、调用 AI 或数据库 → 再通过 OpenWA 回复用户。

🧩 适用场景：通知、客服、自动化工作流

第一个典型场景是业务通知。比如订单支付成功、物流状态更新、预约提醒、课程开播提醒，都可以由业务系统调用 OpenWA API 发送 WhatsApp 消息。相比邮件和短信，WhatsApp 在很多地区的打开率更高，也更适合和用户继续对话。

第二个场景是多账号客服。团队可以为不同业务线创建不同 Session，通过 Dashboard 管理状态，再把消息事件转发到自己的 CRM 或工单系统。例如客服 A 负责售前，客服 B 负责售后，不同号码都挂在同一个 OpenWA 实例上，后端根据 Session 或标签做路由。

第三个场景是 n8n 自动化。OpenWA 明确强调 n8n Integration，这对自动化爱好者非常友好。你可以把 WhatsApp 消息变成 n8n Trigger，再连接 Airtable、Notion、Google Sheets、Telegram、飞书或自建接口。像“客户发来订单号自动查物流”“用户发关键词返回下载链接”“群里有新消息自动归档”这类流程，都可以快速搭起来。

第四个场景是内部运维通知。比如服务器告警、定时任务失败、A 股监控异动、爬虫状态提醒，都可以通过 OpenWA 发到指定 WhatsApp 账号或群组。当然，如果已经有 Telegram 通道，WhatsApp 可以作为海外用户或备用通知渠道。

⚖️ 同类对比：为什么不是直接用第三方平台

方案优点局限
官方 WhatsApp Business API合规、稳定、适合企业规模化接入流程和费用门槛较高，灵活性受平台限制
第三方 SaaS 网关上手快，有客服和托管能力数据与账号依赖供应商，高级功能常收费
自写 whatsapp-web.js 脚本极度灵活，代码可控缺少 Dashboard、权限、Webhook、日志和部署规范
OpenWA开源、自托管、REST API、Webhook、多会话、Docker仍需自己负责服务器、账号风控和运维稳定性

OpenWA 的优势不是“完全替代官方商业 API”，而是给开发者一个可控、可二次开发、可接入自动化系统的自托管方案。对个人开发者、小团队、测试环境、内部工具、低成本自动化来说，它的性价比很高。

但也要注意，WhatsApp 生态本身对自动化行为有风控。批量群发、陌生人营销、异常频率都可能导致账号受限。我的建议是把 OpenWA 用在明确授权的通知、客服、内部协作和低频自动化上，同时配置速率限制、IP 白名单、日志审计和备用账号策略。

🛡️ 上线建议：安全和稳定性要提前设计

部署 OpenWA 时，第一步一定是保护 API Key。不要把 API 暴露在公网裸奔，更不要把 Swagger 直接开放给所有人。建议通过 Nginx 加 HTTPS，限制后台访问 IP，并在 OpenWA 内部启用 API Key Auth、CIDR Whitelisting 和 Rate Limiting。

第二步是数据持久化。Session 数据、媒体文件、数据库文件都应该挂载到宿主机目录或独立存储卷。否则容器重建后，登录状态、历史配置或媒体缓存可能丢失。生产环境建议至少使用 PostgreSQL，媒体较多时再考虑 S3 或 MinIO。

第三步是日志和备份。OpenWA 支持 Audit Logging，这对排查“谁调用了接口、什么时候发送了消息、哪次 Webhook 失败”很关键。建议配合 Docker 日志、定时数据库备份和健康检查。README 中也提到 Health Checks，适合接入 Kubernetes 或简单的 uptime 监控。

第四步是频率控制。即使技术上支持 Bulk Messaging，也不代表可以无节制群发。更稳的做法是对每个 Session 设置发送队列，比如每分钟固定数量、失败重试、黑名单过滤、用户退订标记。这样既保护账号，也保护品牌信誉。

✅ 总结：适合开发者自建的 WhatsApp 自动化底座

OpenWA 的价值，在于把 WhatsApp 这种强用户触达渠道，包装成开发者熟悉的 API、Webhook、Dashboard 和 Docker 服务。它不是一个简单脚本，而是一套包含多会话、媒体消息、群组、频道、标签、代理、限流、白名单、审计、数据库和缓存适配的消息网关。

对于想做客户通知、社群运营、n8n 工作流、跨境业务自动回复、内部运维提醒的团队来说，OpenWA 很值得测试。它的部署门槛低，两个命令就能跑起来；架构又足够开放，后续可以逐步切换 PostgreSQL、Redis、MinIO 等生产组件。

如果你只是想快速验证 WhatsApp 自动化，OpenWA 可以先作为实验平台；如果你已经有稳定业务流程，它也可以作为自托管消息中台的一部分。关键是别把它当作无脑群发工具，而要把它放进规范的权限、日志、限流和备份体系里使用。

项目地址：https://github.com/rmyndharis/OpenWA