WhatsApp Business API alternative: the four real paths (and which one you actually want).

Not in the Meta-supplied sense. There is no first-party REST endpoint that accepts the same shape and skips the verified-business and template gates. Every BSP that markets itself as an 'alternative' is reselling Meta's WhatsApp Cloud API with their own console on top, and inherits all the same gates. The genuine non-API paths are different products entirely: open-source libraries that speak WhatsApp's multi-device protocol, hosted SaaS that runs WhatsApp Web for you, and local drivers that act on the official desktop app via OS accessibility frameworks. Each replaces a different slice of what people actually want when they search 'alternative'.

Marketing convention. The 'alternative' framing in those listings means 'a different vendor for the same job', not 'a different protocol path'. Wati, Twilio, 360dialog, Infobip, Gallabox, Tidio, respond.io, AiSensy, Interakt and most of the rest are Business Solution Providers; they hold a relationship with Meta and resell the Cloud API plus their own UI, CRM glue, and template management. If your blocker is the price of one BSP, switching to another can help. If your blocker is the Business API model itself (verification, templates, opt-in, separate number, per-message billing), switching BSPs changes nothing.

Define safe. Both are mature, widely used, and free. Baileys speaks WhatsApp's multi-device protocol directly; whatsapp-web.js drives the web client through Puppeteer. They work, and a lot of teams ship with them. The risk is account-level: WhatsApp's anti-automation systems do flag and ban accounts that use these libraries, especially for outbound that looks bulk or business-like. The risk is not deterministic; some accounts run for years, some get banned in days. The honest framing: treat any account you operate this way as disposable and do not use a number you would be sad to lose. Read the libraries' own README files for current banning patterns.

Two main differences. First, surface: Baileys speaks the multi-device protocol over websockets, which is the surface Meta most actively monitors for non-WhatsApp clients. The MCP server does not speak the protocol at all; it drives the official WhatsApp Catalyst app on your Mac through the same accessibility framework that VoiceOver and other assistive tools use. From Meta's perspective the network traffic is just the official client doing its job. Second, fit: the MCP server is built for a single human's account on a single Mac and exposes itself as MCP tools an AI host calls over stdio. Baileys is a library you wire into your own service; you get more flexibility and more responsibility (session storage, reconnects, multi-device pairing, and the ban-mitigation playbook are all yours).

It re-reads the chat. After the send keystroke fires, the server sleeps 1.0 seconds, walks the WhatsApp accessibility tree, collects every AXGenericElement, and looks for one whose accessibility description begins with the literal prefix 'Your message, '. WhatsApp's Catalyst client labels each outgoing bubble with that prefix plus the message body and a trailing time. The server strips the time suffix using the regex ',\\s+\\d{1,2}:\\d{2}\\s*[APap][Mm]' and compares the remaining text to what was just typed. Match returns verified:true in the JSON-RPC response. Mismatch returns verified:false with the visible bubble in a warning field. The chat is the receipt; there is no Meta endpoint to ask.

Groups and one-to-one chats: yes, anything that appears in the search and chat list of the desktop app is reachable. The server uses whatsapp_search to find the group by name, whatsapp_open_chat to open it, and whatsapp_send_message to type. Status updates and the broadcast-list mechanic on the consumer app are not currently first-class tools because the desktop app has limited surface for them. The README's tool table is the source of truth for what is exposed today.

Out of scope. The server depends on the macOS Accessibility framework (AXUIElement, kAXUIElementRoleAttribute, the Catalyst app's specific subrole tree). Porting would mean rewriting the entire interaction layer against UI Automation on Windows or AT-SPI on Linux, plus accommodating the very different WhatsApp clients there. If you are not on a Mac, the closest equivalents are the open-source web client libraries (Baileys, whatsapp-web.js), with the account-risk caveat above.

Yes. Once you are sending opted-in messages to thousands of recipients per day, you want the Business API regardless of which BSP packages it. The MCP server is bottlenecked by one Mac running one WhatsApp app; it is not designed for fan-out. The split is clean: agent-driven personal messaging, internal coordination, and one-on-one workflows belong on the local driver; high-volume verified-business outbound belongs on the Cloud API. They can coexist in the same MCP host config: one stdio entry for the local server, one HTTP entry for a Cloud-API wrapping MCP, and the agent picks based on which account is supposed to send.

It uses the official desktop app and macOS Accessibility, which are sanctioned APIs (Accessibility is the same surface VoiceOver uses). The WhatsApp consumer terms still govern what you do with your account. Sending the kind of messages you would normally type to people you would normally type them to is fine. Using any automation, including the MCP server, to mass-message strangers, scrape contact graphs, or otherwise behave like a business on a personal account, is the kind of activity that gets accounts banned, exactly as it would if you did the same thing manually. Read the consumer terms before pushing volume.

The MCP server registers as a stdio MCP server in any host that speaks the protocol (Claude Code, Cursor, Windsurf, Claude Desktop, any custom client). Once registered, an agent can call whatsapp_search to find a contact by name, whatsapp_open_chat to focus the chat, whatsapp_get_active_chat to read recent context, and whatsapp_send_message to send. The recommended workflow in the README is exactly that four-step sequence. From the agent's side it is just typed tool calls; from the recipient's side it is a normal message in your normal chat thread. That is the use case that none of the BSP-style alternative listings address.