Top WhatsApp Chatbot Frameworks for Developers (2026)
A developer-focused survey of WhatsApp chatbot frameworks and libraries — BuilderBot, Typebot, Rasa, Microsoft's stack, plus Baileys and whatsapp-web.js — with selection criteria, code, and honest ToS/ban-risk guidance.
- Before picking a framework, pick a transport: Meta's official WhatsApp Cloud API (ToS-compliant, per-message billing) or unofficial WhatsApp Web automation via Baileys / whatsapp-web.js (free, personal numbers, real ban risk).
- BuilderBot is the most flexible open-source flow engine (MIT, TypeScript) — it lets you swap official and unofficial backends behind one codebase. Typebot is the best visual/no-code builder, but its WhatsApp channel is gated behind a paid license even when self-hosted.
- For NLU/LLM-driven dialogue, Rasa Pro + CALM is the strongest on-prem option (Python, Apache-2.0 core); bolt on a Cloud API or Twilio transport since Rasa has no first-party WhatsApp channel.
- Microsoft Bot Framework SDK is now legacy — long-term support ended December 31, 2025; new work goes to the Microsoft 365 Agents SDK and Copilot Studio. Wit.ai and Dialogflow are NLU layers, not full frameworks.
- Use unofficial libraries for prototyping and personal bots; move commercial, marketing and notification workloads to the official Cloud API.
First decision: official transport vs unofficial automation
Before you compare a single framework, you have to make one architectural choice that shapes everything else: how your bot actually talks to WhatsApp. There are two tiers, and almost every tool in this guide is really a wrapper, a flow engine, or an NLU brain that sits on top of one of them.
The first tier is Meta's official WhatsApp Business Cloud API. It is the only sanctioned path, runs on a verified WhatsApp Business Account, and is billed per message. Automation itself will not get your number banned — that is the whole point of the API — but the account can still be restricted for policy violations such as spam, a low quality rating, or sending unapproved templates, and it requires business verification, approved message templates, and acceptance of opt-in and 24-hour-window rules. The second tier is unofficial WhatsApp Web automation — libraries like Baileys and whatsapp-web.js that connect a regular personal or business number through WhatsApp's Linked Devices protocol. They are free, fast to start, and need no verification, but they reverse-engineer WhatsApp and therefore violate its Terms of Service. That carries a genuine, documented risk of a permanent number ban.
How to choose: the criteria that matter
"Best" depends entirely on your constraints. When you evaluate any WhatsApp chatbot framework, score it against the dimensions below rather than star counts alone.
- Transport: does it run on the official Cloud API, an unofficial library, or both? This determines ToS compliance and ban risk more than any feature.
- License: a real OSI license (MIT, Apache-2.0) gives you freedom to self-host and modify. Watch for source-available licenses like FSL, or features paywalled even in self-hosted builds.
- Maintenance health: WhatsApp Web changes often. A library or framework that lags behind breaks. Check recent releases and issue activity, not just the README.
- Language and ecosystem: TypeScript/Node.js (BuilderBot, Baileys, whatsapp-web.js) versus Python (Rasa) versus polyglot SDKs (Microsoft) determines who on your team can own it.
- NLU / LLM: is conversational AI built in (Rasa, Dialogflow, Wit.ai), or do you bring your own model and write the dialogue logic (BuilderBot, the raw libraries)?
- Self-host vs SaaS cost: open-source self-host (BuilderBot, Rasa) versus visual SaaS with paid tiers (Typebot, Copilot Studio).
- Resource footprint: a WebSocket client (Baileys) is far lighter than a headless-Chromium one (whatsapp-web.js), which matters at scale or on small servers.
The frameworks at a glance
Here is the quick reference. Versions and statuses were verified in mid-2026 — re-check each project before you commit, since this space moves quickly and release cadences are fast.
| Tool | Type | Language | Transport | License | Built-in NLU/LLM | Status |
|---|---|---|---|---|---|---|
| BuilderBot | Flow framework | TypeScript | Cloud API, Twilio, Baileys, Venom, WPPConnect | MIT | No (bring your own) | Active (v1.3.x, 2025) |
| Typebot | Visual builder | TypeScript | Cloud API | FSL (source-available) | No (integrations) | Active; WhatsApp gated to paid |
| Rasa Pro + CALM | NLU/dialogue framework | Python | Custom connector / Twilio / Cloud API | Apache-2.0 core | Yes (LLM-driven dialogue) | Active; OSS in maintenance |
| Microsoft 365 Agents SDK | Agent SDK | C#/JS/Python | Third-party adapters (e.g. Infobip) | MIT (SDK) | Via Azure/Copilot | Active (successor to Bot Framework) |
| Bot Framework SDK | Bot SDK | C#/JS/Python | Third-party adapters | MIT | Via LUIS/Azure | Legacy; LTS ended Dec 31, 2025 |
| Baileys | Library | TypeScript/JS | Unofficial (Linked Devices) | MIT (WhiskeySockets fork) | No | Active (v7 RC; pin exact version) |
| whatsapp-web.js | Library | JavaScript | Unofficial (Puppeteer) | Apache-2.0 | No | Active (v1.34.x) |
BuilderBot — the flexible open-source flow engine
BuilderBot (npm @builderbot/bot, repo codigoencasa/builderbot) is the framework I reach for first when I want full code control without rebuilding the plumbing. It is MIT-licensed, written mostly in TypeScript, actively maintained through late 2025, and won first prize at OpenExpo Europe 2024. Its defining feature is that it is provider-agnostic: the same flow logic runs on Meta's Cloud API, Twilio, or unofficial backends like Baileys, Venom, and WPPConnect. You can prototype on Baileys, then switch a single provider import to the Cloud API for production without rewriting your conversation.
You scaffold a project with npm create builderbot@latest, then describe conversations as flows. BuilderBot has no built-in NLU — you wire in your own model or LLM where you need understanding — which keeps it lean and unopinionated.
import { createBot, createProvider, createFlow, addKeyword } from '@builderbot/bot'
import { MemoryDB } from '@builderbot/bot'
// Swap this provider for MetaProvider (Cloud API) in production
import { BaileysProvider } from '@builderbot/provider-baileys'
const welcome = addKeyword(['hi', 'hello', 'menu'])
.addAnswer('Hi! I am a demo bot.')
.addAnswer('Reply *1* for sales or *2* for support.', { capture: true },
async (ctx, { fallBack, flowDynamic }) => {
if (!['1', '2'].includes(ctx.body)) return fallBack('Please reply 1 or 2.')
await flowDynamic(ctx.body === '1' ? 'Connecting you to sales…' : 'Opening a support ticket…')
})
const main = async () => {
await createBot({
flow: createFlow([welcome]),
provider: createProvider(BaileysProvider),
database: new MemoryDB(),
})
}
main()Pros: fast to prototype, MIT-licensed, official-or-unofficial backends behind one codebase, growing plugin ecosystem. Cons: when paired with an unofficial provider it inherits that provider's ban and ToS risk, and you supply your own NLU/LLM layer.
Typebot — visual flows for teams that prefer no-code
Typebot (repo baptisteArno/typebot.io, by TYPEBOT SAS in France) is a visual, drag-and-drop conversation builder you can self-host. If your bot is mostly structured flows — lead capture, FAQs, booking — and you want non-developers to edit it, Typebot's builder is excellent and the developer experience is polished.
Two caveats matter for developers. First, licensing: Typebot uses the Functional Source License (FSL), which is source-available, not a traditional OSI open-source license. You can self-host freely, code converts to MIT after two years, but there is a competitive-use restriction. Second, and more important in practice: per Typebot's own pricing and docs, the WhatsApp integration (alongside SSO) is gated behind a paid plan even when you self-host. Paid tiers start around $39/month. So "self-hosted Typebot for WhatsApp" is not free in the way BuilderBot or Rasa Open Source are — confirm the current pricing page before you commit, since tiers change.
Rasa, Dialogflow, and Wit.ai — the conversational AI layer
When your bot needs to genuinely understand free-form language rather than match keywords, you reach for an NLU or LLM-driven dialogue engine. These are not WhatsApp frameworks per se — they are the brain you bolt onto a transport.
Rasa is the heavyweight for teams that need on-premise control of their data. The core is Apache-2.0, but note the direction of travel: Rasa Open Source is now in maintenance mode, and the company's roadmap centers on Rasa Pro with CALM (Conversational AI with Language Models), an LLM-driven approach to dialogue. Rasa Pro offers a free developer license for exploration, an extended developer license for limited production, and a paid license at scale. Rasa has no first-party WhatsApp channel — you connect it through a custom connector or via Twilio's WhatsApp Business API or Meta's Cloud API. It's the heaviest stack to operate (Python, training pipelines) but the strongest for data control and complex assistants.
Dialogflow (now the Conversational Agents console combining Dialogflow CX and Vertex AI Agent Builder) has direct WhatsApp Business API connectivity, which makes it the lower-friction managed option. Be aware the standalone Dialogflow CX console was deprecated on October 31, 2025; new work routes through the Conversational Agents console. Wit.ai, Meta's free NLU engine, has broad language coverage but no built-in WhatsApp channel at all — you handle the integration yourself and use it purely as an intent/entity extractor in front of a Cloud API transport.
- Rasa: maximum control, on-prem/data-residency friendly, Python, heaviest to run. No native WhatsApp channel — connect via Twilio or Cloud API.
- Dialogflow / Conversational Agents: managed, direct WhatsApp connectivity, Google-hosted. CX console deprecated Oct 31, 2025 in favor of Conversational Agents.
- Wit.ai: free NLU only, broad languages, no WhatsApp channel — bring your own transport and glue code.
Microsoft Bot Framework — now legacy
If you find tutorials pointing you at the Microsoft Bot Framework SDK, treat them as legacy. Microsoft has retired the Bot Framework SDK: long-term support ended December 31, 2025. Existing bots keep running, but there are no new features or support tickets. Microsoft now directs new work to the Microsoft 365 Agents SDK (generally available, with C#, JavaScript, and Python) and to Copilot Studio for low-code agents.
WhatsApp was never a native Azure Bot Service channel either — you reached it through third-party adapters such as the Infobip marketplace connector. For a new WhatsApp chatbot in 2026, there's little reason to start here unless you are already deeply invested in the Azure and Microsoft 365 ecosystem; even then, build on the current Agents SDK, not the retired Bot Framework SDK.
Going library-level: Baileys and whatsapp-web.js
Sometimes you don't want a framework — you want a direct WhatsApp client to build on. The two dominant Node.js options are Baileys and whatsapp-web.js. Both are unofficial: they automate a regular number via WhatsApp's Linked Devices protocol, so the ban-risk caveat from the first section applies in full.
Baileys (repo WhiskeySockets/Baileys, npm baileys) is a socket-based TypeScript/JS library. It speaks WhatsApp's multi-device WebSocket protocol directly — no browser — so it is light on resources and scales well. The original repository was taken down by its initial author; the maintained community fork now lives under the WhiskeySockets organization and its maintainers, and is MIT-licensed. At the time of writing the v7 line is a release candidate (the 7.0.0-rc series) that introduces breaking changes versus v6, so pin an exact version rather than a caret range and read the changelog before upgrading. The maintainers are explicit that the project is unaffiliated with WhatsApp and that they do not condone ToS-violating use, and they discourage spam and bulk automation.
import makeWASocket, { useMultiFileAuthState } from 'baileys'
const { state, saveCreds } = await useMultiFileAuthState('auth')
const sock = makeWASocket({ auth: state })
sock.ev.on('creds.update', saveCreds)
sock.ev.on('messages.upsert', async ({ messages }) => {
const msg = messages[0]
if (!msg.message || msg.key.fromMe) return
const text = msg.message.conversation ?? ''
if (text.toLowerCase() === 'ping') {
await sock.sendMessage(msg.key.remoteJid!, { text: 'pong' })
}
})whatsapp-web.js (repo pedroslopez/whatsapp-web.js, docs wwebjs.dev) takes the opposite approach: it drives WhatsApp Web in headless Chromium via Puppeteer. It requires Node.js 18+, is at v1.34.x in 2026, and is actively maintained. The browser approach gives close parity with the web client but a heavier footprint and recurring breakage when Chrome or WhatsApp Web updates — for example the Chrome 132 "target closed" Puppeteer issue in January 2025. It is friendlier for beginners because of its event-driven API and large community.
const { Client, LocalAuth } = require('whatsapp-web.js')
const qrcode = require('qrcode-terminal')
const client = new Client({ authStrategy: new LocalAuth() })
client.on('qr', (qr) => qrcode.generate(qr, { small: true }))
client.on('ready', () => console.log('Client is ready'))
client.on('message', async (msg) => {
if (msg.body === 'ping') await msg.reply('pong')
})
client.initialize()Putting it together: which to choose
Match the tool to the job, and let your transport decision lead:
- Prototyping or a personal/internal bot, fast: BuilderBot on Baileys, or whatsapp-web.js directly. Cheapest and quickest — just keep it low-volume and consent-based.
- Production commercial bot, code-first: BuilderBot on the Meta Cloud API. You keep your flow code and gain ToS compliance.
- No-code/visual flows owned by a non-engineering team: Typebot — budget for the paid WhatsApp license.
- Complex, language-understanding assistant with strict data control: Rasa Pro + CALM (Python), connected via Twilio or the Cloud API.
- Managed NLU with the least glue code: Dialogflow / Conversational Agents, which connects to WhatsApp directly.
- Heavy Microsoft 365 / Azure shop: Microsoft 365 Agents SDK plus a WhatsApp adapter — not the retired Bot Framework SDK.
One pattern is common to all of them and worth automating early: validate recipient numbers before you send. Bad numbers waste Cloud API spend on undeliverable templates and, on unofficial stacks, repeatedly messaging dead or wrong numbers is exactly the behavior that triggers blocks and bans. A read-only check that confirms a number is on WhatsApp — and returns the public name, profile picture, about text, and business flag — keeps your sending lists clean on any framework.
Frequently asked questions
On any framework — Cloud API or unofficial — undeliverable numbers waste budget and trigger bans. Our hosted API checks if a number is on WhatsApp and returns the public profile picture, display name, about text, and business flag. Read-only, no QR scan, no ban risk.
Explore the WhatsApp Profile APINeed cheap numbers to create, verify or warm up WhatsApp accounts for testing? GrizzlySMS rents virtual numbers for WhatsApp verification from under $1.
Get a WhatsApp numberSources & further reading
- BuilderBot GitHub repository
- OpenExpo Europe 2024 awards (BuilderBot)
- Baileys (WhiskeySockets) GitHub repository
- Baileys releases (npm version history)
- whatsapp-web.js GitHub repository
- WhatsApp Business Platform pricing (Meta)
- Microsoft Bot Framework SDK retirement guidance
- Rasa product release and maintenance policy
- Typebot GitHub repository (license)
- Typebot pricing (WhatsApp gated to paid plans)
- Dialogflow release notes