tulir/whatsmeow

If you need programmatic WhatsApp messaging in a Go service, whatsmeow is the library to evaluate first. It is a protocol client, not a bot-hosting framework: you get the connection and message plumbing, and you write everything around it.

The problem

A developer wants to send a group notification, ingest customer messages into a CRM, or maintain a two-way support inbox on WhatsApp. Doing this through manual phone interaction or ad-hoc screen automation does not scale and does not compose with server code. whatsmeow moves that work into a Go process: you authenticate a session, subscribe to events, and call send methods from your own code. The result is an application that can send, receive and react to WhatsApp traffic as part of a normal backend workflow, rather than a person operating a phone.

What's different

This is a library for the WhatsApp web multidevice protocol, so the unit of reuse is the API surface in Go rather than a prebuilt gateway or hosted product. The documented core is broad: sending text and media to private chats and groups, receiving messages, group management and change events, invite links and joining via invite messages, typing and read/delivery receipts, app-state read/write for contact lists and pin/mute status, and retry receipts when decryption fails. That maps closely to what a messaging integration usually needs, which reduces the amount of protocol work you have to fill in yourself.

The trade-off is that you own the application layer. Session persistence, reconnection policy, event handling, storage of messages and deployment are not packaged for you; they are the integration work. Status messages are marked experimental and may not work for large contact lists, and the feature list explicitly excludes broadcast-list messages and calls. Some of these limits stem from what WhatsApp web itself supports, but they still define what your product can claim.

Who should try it

Good fit: a Go backend where WhatsApp is one channel among several, and the team is comfortable owning session lifecycle, storage choices and event dispatch. A small internal notification daemon or a CRM-integrated inbox is a plausible first project. Poor fit: someone looking for an off-the-shelf bot with configuration files, or a team needing calls or broadcast lists, since those are documented as out of scope. If your stack is not Go, the library does not offer a language-neutral service path; read the usage documentation and API reference before assuming a wrapper will be enough.

Requirements and limitations

You need a Go codebase and the ability to run a long-lived process that maintains an authenticated WhatsApp session. Beyond initial setup, the ongoing concern is session state: credentials and keys must survive restarts and be handled with care, because losing or mishandling them affects the connection. Message decryption failures are part of normal operation, which is why the library exposes retry receipts; your code has to respond to those events and decide what to show users.

The feature gaps matter at the design stage. No calls and no broadcast-list sending should be discovered before you promise those capabilities. Experimental status messages should be treated as a bonus, not a foundation for a mass-notification product. The project points protocol questions to a dedicated Q&A section and general discussion to a Matrix room, so expect to consult those as you build.

HotRepo's take

HotRepo recorded the project on the daily GitHub Trending board once, on 2026-10-28, at 7,687 stars with +14 stars that day. That single dated observation says nothing about whether interest is rising or fading, and persistence cannot yet be judged. For adoption, the decisive check is the documented feature list: confirm that every WhatsApp capability your product needs is in the implemented set and that any missing one is acceptable. Treat the library as infrastructure you integrate, not a finished messaging product.