Python
Total control and no ceiling. There is no official Meta Python SDK for WhatsApp, so you use an HTTP client against the Graph API and a web framework for the webhook. Everything else, from conversation memory to retries, is yours to write.
THE DIY ROUTES, HONESTLY
Python scripts, n8n workflows and the open-source repos on GitHub all talk to the same Meta Cloud API. The API is the easy part. What takes the months is business content, conversation state, live calendar availability, handover, template approvals and being on call when it breaks.
Whether you write Python, drag nodes in n8n or clone a repo, the WhatsApp part is identical. You register an HTTPS endpoint as a webhook. Meta sends a verification request with a mode, a verify token you chose and a challenge string, and your endpoint echoes the challenge back. After that, incoming messages arrive as webhook events, and you send replies by posting to the messages endpoint for your phone number ID with an access token.
Two rules shape everything you build on top. First, a customer messaging you opens a 24-hour customer service window in which you can reply freely. Second, outside that window you can only send a message template that Meta has approved in advance, in a category Meta decides. Every framework, node and repo lives inside those two rules.
So the choice between routes is not really about the API. It is about who builds and owns everything the API does not do.
Total control and no ceiling. There is no official Meta Python SDK for WhatsApp, so you use an HTTP client against the Graph API and a web framework for the webhook. Everything else, from conversation memory to retries, is yours to write.
A workflow automation tool with WhatsApp Business Cloud nodes, self-hostable, good at wiring one system to another. Excellent for a defined sequence. Weaker when a conversation wanders, because a workflow run is not a conversation.
The same idea as n8n with less hosting to run and less depth in the branches. Fine for notifications and record-keeping, harder to make pleasant as the thing a customer talks to.
A wide range, from thin Cloud API wrappers to full bot frameworks. Read which API each one uses before anything else, because that single fact decides whether your number is safe.
Ships with the parts DIY has to build: content review, live calendar availability, handover with context, template handling and someone else being on call. You trade some control for a working front desk today.
The WhatsApp connection is one line in this table. Everything else is the project.
| The job | Building it yourself | A no-code product |
|---|---|---|
| Connecting the number to Meta | A day of forms, tokens and verification. | A guided sign-up. |
| Understanding a free-text question | Choose and integrate a model, write the prompting, handle bad inputs and refusals. | Included, and tuned for customer enquiries. |
| Knowing your prices and services | You build the content store and the retrieval, then keep it current. | Read from your website, then reviewed by you before go-live. |
| Live calendar availability | OAuth, free-busy lookups, time zones, buffers, double-booking races. | Connect Google Calendar and set the booking rules. |
| Handover to a person | Decide the trigger, route it, and carry the context so nobody repeats themselves. | A rule you choose, with the conversation summary attached. |
| Templates and approvals | Draft, submit, handle rejections, resubmit, track category changes. | Handled for the messages the product sends. |
| Hosting, uptime and monitoring | Yours, including the Saturday night it stops. | Included in the fee. |
| Keeping up with Meta | API versions deprecate and policies change; you track them. | Absorbed by the vendor. |
Open-source WhatsApp bots split into two very different families, and the difference matters more than stars or last commit date.
The first family talks to Meta's official Cloud API. These are ordinary API wrappers, and building on one is a normal engineering decision.
The second family automates WhatsApp Web or reimplements the client protocol, which is why they can look so much easier to start with: no Meta forms, no business verification. WhatsApp's terms cover which clients may connect, and a number used through an unofficial client can be blocked. If you are considering one, read the business terms first and decide with your eyes open, because the number at risk is usually the one printed on your shopfront.
A working prototype is genuinely short: a small web app that verifies the webhook, reads the incoming message and posts a reply. You can get there in an evening.
Production is a different list. You will want request signature verification, a public HTTPS endpoint with a real certificate, idempotent handling because Meta retries deliveries, a queue so a slow model call does not time out the webhook, storage for conversation state, and structured logging you can search when a customer says the bot told them something odd.
Then come the business pieces: the calendar client, the rules that decide what may be offered, the handover, and the admin screen someone non-technical uses to change a price. That admin screen is usually the moment a DIY WhatsApp chatbot becomes a product you now maintain.
n8n suits this better than most automation tools because you can self-host it, branch properly and call any HTTP API. A trigger receives the WhatsApp event, nodes decide what happens, a node sends the reply.
The friction shows up in conversation. A workflow is a run with a beginning and an end; a customer conversation is a thread that pauses for two hours and resumes with the word actually. You end up building your own state store, your own way of knowing which run owns which chat, and your own guard against two runs answering the same person at once.
It is a good fit when the WhatsApp part is a step inside a bigger internal process you already run in n8n. It is a harder fit when the WhatsApp thread is the product.
The logic is specific to your operation and no product models it; you have an engineer who will still be here in a year; you need it inside systems a vendor cannot reach; or the build itself is the point.
The job is answering customers, quoting published prices and booking appointments; nobody on the team wants to be paged at 9pm on a Saturday; and the value is in being live this month rather than owning the code.
Before you scope a build, see what finished looks like. Send Elily your website link on WhatsApp and she answers as your business, so your build estimate has something real to be measured against.
QUESTIONS BEFORE YOU START
Yes. There is no official Meta Python SDK, so you call the Cloud API over HTTP and host a webhook endpoint in a framework such as Flask or FastAPI. The prototype is quick; conversation state, calendar logic, handover and hosting are what make it a project.
There are many. Check which API each project uses first. Projects built on Meta's official Cloud API are a normal dependency; projects that automate WhatsApp Web sit outside WhatsApp's business terms and put the number itself at risk.
n8n can receive WhatsApp Business Cloud events and send replies, which covers the plumbing. You still add conversation state, your business content, calendar availability and a handover path, because a workflow run is not the same thing as a conversation.
You need a publicly reachable HTTPS endpoint that Meta can deliver webhooks to, so yes for any DIY route, whether that is a container, a serverless function or a hosted n8n instance. A no-code product hosts that for you.
Meta does not charge for API access itself; it charges by message category, and the rates differ by country. Most inbound service replies fall inside the 24-hour customer service window, which Meta's current published rules do not charge for. Hosting, the model and your time are separate.
KEEP READING
Rest of the WhatsApp chatbot guide
THE NEXT MESSAGE CAN BE HERS
Send Elily your website link on WhatsApp. Seeing the finished behaviour is the fastest way to decide which parts are worth writing yourself.
Last updated