openclaw - 💡(How to fix) Fix [Feature]: Native WAHA channel adapter (alongside Baileys) for stabler WhatsApp [1 participants]

Summary

Request native WAHA (https://github.com/devlikeapro/waha) as a first-class channel in OpenClaw, alongside the existing Baileys-backed whatsapp channel. WAHA is a self-hostable, Dockerized HTTP+webhook gateway around the WhatsApp Web protocol that abstracts the Baileys (@whiskeysockets/baileys) library behind a stable REST API and a webhook event stream.

Motivation

The current whatsapp plugin is a direct Baileys integration. In production it works, but it carries the well-known instability surface of the unofficial WhatsApp Web protocol:

• Frequent Web connection closed (status 408) storms — auto-recoverable but noisy and very visible in logs/dashboards.
• NOWEB store sync stalls where the session reports WORKING but inbound message events stop surfacing for tens of minutes (we currently ship a custom watchdog + auto-restart for this).
• WhatsApp Web protocol drift causes periodic regressions that ripple through every Baileys-using project (recent activity in this repo: #70856, #72262, #72489, #72656, #72735, #72895, etc.).

WAHA decouples OpenClaw from Baileys upgrades. It runs in its own container, exposes a REST API for outbound and a webhook delivery stream for inbound, and supports multiple engines (NOWEB, WEBJS, GOWS) so users can pick whichever is most stable for their account/region. Several OpenClaw users (including us) already run WAHA alongside Baileys — currently we use it for outbound alerts only because there is no native ingest path, so inbound still relies on the Baileys session and remains the failure mode.

Proposed scope

A waha channel plugin (or a whatsapp.engine: "waha" mode on the existing channel) that:

1. Outbound — wraps WAHA's POST /api/sendText, POST /api/sendImage, POST /api/sendFile, POST /api/reactions, etc., behind the same channel send/react/edit/delete actions the existing Baileys path exposes.
2. Inbound — registers a session webhook with WAHA pointing at a gateway-served endpoint (e.g. /hooks/waha/<session>), parses WAHA's message, message.reaction, message.ack event payloads, and routes them through the same inbound pipeline (session-key lookup, allowFrom enforcement, group policy, plugin pre-hooks like outbound-finalizer) used by Baileys today.
3. Auth / session lifecycle — surface WAHA's session lifecycle (STARTING, SCAN_QR_CODE, WORKING, FAILED, STOPPED) into the openclaw status / control-UI views the same way Baileys connection state is surfaced today.
4. Config — accept the WAHA base URL, API key, and session name as channel config; reuse the existing dmPolicy / allowFrom / groupPolicy semantics so existing config translates 1:1.

Why I think this is a good fit

• WAHA's webhook + REST interface matches the shape of OpenClaw's existing channel adapters (Slack events, Telegram webhooks, etc.) — so this is a routine adapter, not a new architecture.
• The hooks endpoint is already generic and authenticated; the only piece missing is a parser/translator that turns WAHA webhook payloads into the channel inbound shape OpenClaw already expects.
• Baileys is unlikely to fundamentally stabilize as long as it's reverse-engineered. Giving users an opt-in WAHA path provides a stable alternative without dropping the Baileys path that works for many.
• Lowers the maintenance burden inside OpenClaw: every Baileys upgrade currently risks regressions in whatsapp plugin code; with WAHA, the gateway only depends on a stable REST contract, and Baileys upgrades are WAHA's problem.

Workarounds we are running locally today

• A custom watchdog (personal-whatsapp-408-storm-watchdog.sh) for 408 storms — alert-only since no per-channel restart RPC exists.
• A custom watchdog (waha-inbound-cursor-stalled-watchdog.sh) that detects Baileys-inbound silence-with-WORKING-status and auto-restarts the WAHA(-backed) session.
• Polling the WAHA /api/messages endpoint from cron every few minutes for inbound, because there is no native WAHA→OpenClaw ingest path. This is the polling-versus-realtime gap that motivated the request — sub-second webhook delivery would replace it cleanly.

If a WAHA channel plugin existed, all three of these would go away.

Happy to help

Glad to scope or contribute. Conceptually this looks like the existing slack or telegram channel adapters: an inbound webhook handler, an outbound REST client, and config wiring. If maintainers prefer, we can start with an out-of-tree plugin and PR it in once stable.