A developer writing on dev.to has published Whappr, a self-hosted Docker gateway that connects a single WhatsApp account to an AI agent. The author describes it as a thin Hono API sitting in front of whatsapp-web.js, the library that drives WhatsApp Web in a browser session. The project is MIT-licensed and hosted at github.com/whappr/whappr, according to the post.
The stated motivation is friction in the two existing routes to WhatsApp. The author writes that Meta's official WhatsApp Cloud API requires business verification, message templates and per-conversation pricing, which the author calls heavy for a prototype or an internal assistant. Existing unofficial tools such as WAHA and OpenWA, the author argues, are built to automate WhatsApp broadly rather than to let an agent converse.
Deliberately narrow is how Whappr's mechanism works. Linking a container to a WhatsApp account happens via QR code — the identical flow WhatsApp Web relies on — and because the session lives in a mounted volume, scanning the code is needed just one time. On the inbound side, the operator's agent receives every event as an HMAC-signed webhook: a new message, an edit, a reaction. On the outbound side, a small REST API guarded by a bearer token is how the agent sends replies.
Two design choices follow from that. First, there is no database: messages pass through the gateway and are never stored, so the agent owns its own memory. Second, events are delivered one webhook per event and in order, and each event carries a chat identifier so separate conversations can be routed to separate agent instances. The author also says the gateway handles typing indicators, read receipts, quoted replies and voice notes in both directions, and that the client and protocol packages run on Node and edge runtimes, with a separate package plugging into the Flue agent framework.
The author is explicit about what Whappr leaves out: status updates, channels, broadcasts, group administration, polls, payments and calls. That is a scope decision rather than a roadmap promise, and it is the clearest signal of the intended use case — one agent, one number, one conversation at a time.
The post walks through a five-minute setup: run the gateway container with a generated secret key and a webhook URL, open the local dashboard, enter the secret, and scan the QR code from a phone's linked-devices screen. The documented handler verifies the webhook signature and timestamp, acknowledges immediately with a 204 response, and only then runs the agent and sends the reply. The author flags two production details: acknowledge first because events arrive in order and one slow handler holds up everything behind it, and use the built-in typing helper because WhatsApp clears the typing indicator after roughly 25 seconds while slow models often take longer.
Voice notes are handled as a distinct message kind. Incoming voice messages can be downloaded as a Blob and passed to any speech-to-text API, and replies can be sent as OGG/Opus audio marked as voice. The author also demonstrates a reply tool built once per conversation, where the model chooses only the text and the code fixes the recipient — a pattern the author presents as a guard against prompt injection redirecting a message to another number.
Filtering is offered at the gateway rather than in the agent. Environment variables can restrict which event types and which chat identifiers are forwarded, so events that do not match never leave the container. The author gives the example of keeping an agent inside one team group.
The post positions Whappr against WAHA and OpenWA directly. All three are described as self-hosted, open source and unofficial. The author recommends WAHA for many numbers, browserless engines, channels or status automation and n8n flows, and OpenWA for a full dashboard, stored history, multi-language SDKs or a built-in MCP server. Whappr is recommended for a TypeScript agent that wants a gateway which stays out of the way.
The most consequential caveat is legal and operational rather than technical. Because all three tools drive WhatsApp Web rather than Meta's official Cloud API, the author states that WhatsApp can ban the number that is linked. The advice given is to use a dedicated number, to message only people who expect it, and to keep a fallback; for regulated or large-scale use, the author says to use the official API instead.
Trade-offs belonging to Whappr itself are also listed by the author. No retries accompany each webhook, which is delivered once. Per container, one number. Beneath it all Chromium runs, so memory planning is advised. Breaking changes are expected until v1, since the project is pre-1.0, and pinning exact Docker image and npm package versions is what the author advises.
For freelancers and small studios, the practical appeal is the shape of the thing rather than its feature list. A single container, a QR scan and a signed webhook is a much shorter path to a working WhatsApp demo than business verification and template approval, and the no-storage design means there is no message history to secure or delete. That matters for client work where a prototype has to be stood up quickly and torn down cleanly.
The trade-offs cut the other way for anything client-facing at scale. A single linked number, no retries, no stored history and a pre-1.0 API surface are all reasonable for an internal tool or a proof of concept, and all awkward for a production deployment with paying users. The ban risk is the sharpest constraint: it is a risk to a phone number the client may actually depend on, not a theoretical edge case, and the author does not offer a mitigation beyond using a spare number and keeping a fallback.
Several things remain unknown from the post alone. There is no stated release date for v1, no benchmark or load figure, no pricing because the software is self-hosted and free, and no independent verification of the claims about reliability or ordering. The comparison with WAHA and OpenWA is the author's own assessment of competing tools, not a measured evaluation. The post is a community announcement by the project's author, so every capability described should be read as an author claim until independently reproduced.
Which framework ought to receive an adapter next — Mastra, LangGraph.js or the Vercel AI SDK — is what the author asks readers at the close, along with whether strictly ordered, one-shot webhooks have caused trouble in practice. Open are those questions, and whether the gateway's narrow design holds up beyond the author's own use would be shaped by the answers.