{
  "version": "2",
  "id": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e",
  "title": "Developer Releases Whappr, a Self-Hosted WhatsApp Gateway for TypeScript Agents",
  "summary": "Whappr links one WhatsApp account the way WhatsApp Web does and forwards every event to an agent as an HMAC-signed webhook, with no database and no stored messages — but it is pre-1.0, unofficial, and the author warns linked numbers can be banned.",
  "body": "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.\n\nThe 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.\n\nDeliberately 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.\n\nTwo 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.\n\nThe 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.\n\nThe 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.\n\nVoice 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.\n\nFiltering 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.\n\nThe 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.\n\nThe 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.\n\nTrade-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.\n\nFor 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.\n\nThe 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.\n\nSeveral 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.\n\nWhich 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.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-10-14T10:17:28.267Z",
  "dateModified": "2026-10-14T10:17:28.267Z",
  "eventDate": null,
  "sourcePublicationDate": "2026-10-14T07:59:57.000Z",
  "source": {
    "name": "dev.to",
    "url": "https://dev.to/alexandrubau/i-built-a-lightweight-whatsapp-gateway-that-stores-nothing-4998",
    "kind": "community"
  },
  "practicalImpact": "For freelancers and developers building agent prototypes, Whappr offers a short path to a working WhatsApp integration without business verification or template approval, and its no-storage design simplifies data handling. Editorial interpretation: it is best treated as a prototyping and internal-tool option, not a production channel for client-facing messaging, given the single-number limit, absent retries and the author's own ban warning.",
  "limitations": "The evidence is a single community post by the project's author; capabilities, ordering guarantees and comparisons with WAHA and OpenWA are author claims and were not independently verified. No release date for v1, no performance figures and no pricing are given (the software is self-hosted and MIT-licensed). The post does not state which WhatsApp account types or regions were tested, and it explicitly notes that the project is under active development with possible breaking changes.",
  "keyPoints": [
    "Whappr is a self-hosted Docker gateway that links one WhatsApp account via QR code and forwards inbound events to an agent as HMAC-signed webhooks, with replies sent through a bearer-token REST API.",
    "The author states the gateway stores no messages and keeps no database, leaving conversation memory to the agent; events are delivered once, in order, with no retries.",
    "The project is pre-1.0 and the author advises pinning exact Docker image and npm package versions because breaking changes are expected until v1.",
    "Because it drives WhatsApp Web rather than Meta's official Cloud API, the author warns that WhatsApp can ban the linked number and recommends a dedicated number and a fallback."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-10-14T10:17:28.267Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://dev.to/alexandrubau/i-built-a-lightweight-whatsapp-gateway-that-stores-nothing-4998",
      "publisher": "dev.to",
      "title": "I built a lightweight WhatsApp gateway that stores nothing",
      "publishedAt": 1791964797000,
      "fetchedAt": 1791973029451,
      "hash": "d4c5ce8fcbebfdb972e368816f84ae1b722a9dc40de8612bdc5e834132d4fba1",
      "kind": "community"
    }
  ],
  "claims": [
    {
      "claim": "Whappr is a self-hosted Docker container that links to a WhatsApp account the way WhatsApp Web does and forwards inbound events to an agent as HMAC-signed webhooks.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e#claim-1"
    },
    {
      "claim": "The gateway keeps no database and does not store messages, leaving memory to the agent.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e#claim-2"
    },
    {
      "claim": "Each webhook is delivered once with no retries, one number per container, and the project is pre-1.0 with breaking changes expected until v1.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e#claim-3"
    },
    {
      "claim": "Because the tool drives WhatsApp Web rather than Meta's official Cloud API, the author states WhatsApp can ban the linked number and advises a dedicated number and a fallback.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e#claim-4"
    },
    {
      "claim": "The author positions Whappr against WAHA and OpenWA, recommending WAHA for many numbers and channels/status automation and OpenWA for a dashboard, stored history and multi-language SDKs.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e#claim-5"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e",
    "markdown": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e.md",
    "json": "https://freelancenews.online/news/developer-releases-whappr-a-self-hosted-whatsapp-gateway-for-65fb2a3e.json"
  }
}