How to Build an AI Chatbot on WhatsApp

Most WhatsApp bot tutorials stop at echoing a message back. That is not a product. The hard parts of an AI chatbot on WhatsApp are all in the boring middle: what the model is allowed to know, what it is allowed to do, when it must shut up and fetch a human, and who pays when a template fires.

I have built this stack more than once, most substantially on AI Walay, a multi-tenant WhatsApp Business SaaS, where every tenant had their own phone number, their own knowledge base and their own escalation rules. Below is the architecture I would rebuild tomorrow, plus the mistakes that cost me the most time.

What does it take to build an AI chatbot on WhatsApp?

Five components: a verified WhatsApp Business Account with a Cloud API phone number, a public HTTPS webhook, a conversation store, an LLM call with tool definitions, and a send path back to the Cloud API messages endpoint. Everything else is decoration.

Meta's Cloud API docs describe webhooks as JSON payloads delivered to your server for inbound messages and status updates. Your service is therefore stateless from Meta's point of view; all memory, identity and business logic live on your side. If you have not provisioned the number yet, start with the step-by-step Cloud API setup and come back here.

"Answer the webhook immediately and process asynchronously. Meta retries on timeout, and a slow LLM call is the fastest way to send the same customer three replies."

How does the 24-hour session window change the design?

It splits your bot into two products. Inside the 24-hour customer service window, which opens when the user messages you and resets on each new inbound message, you can send free-form text. Outside it, you can only send templates that Meta has pre-approved.

This is not a billing footnote, it is a state machine. Every outbound message in your system needs to check the window before it picks a send method. I store window_expires_at on the contact row, bump it on every inbound webhook, and make the send function refuse to emit free text when the timestamp has passed.

One design consequence people miss: your AI should never be the thing that reopens a dead conversation. Templates are static and approved, so a model cannot write its way out of a closed window. Build a small set of utility templates that re-engage with a legitimate reason, then let the AI take over once the customer replies.

How do you handle context without burning tokens?

Send a rolling window of recent turns plus a compact summary, not the whole thread. WhatsApp conversations are long-lived and bursty, so replaying every message from six weeks ago is both expensive and worse for accuracy.

My default is the last six to ten turns verbatim, a running summary regenerated every time the thread crosses a turn threshold, and retrieved chunks capped hard. Prompt caching helps if your system prompt is large and stable, which is an argument for keeping tenant-specific facts in the retrieved section rather than baked into the system prompt.

# FastAPI webhook: Meta Cloud API -> LLM -> reply
from fastapi import BackgroundTasks, FastAPI, Request

app = FastAPI()

TOOLS = [
    {
        "name": "lookup_order",
        "description": "Fetch order status from the CRM by order number.",
        "input_schema": {
            "type": "object",
            "properties": {"order_number": {"type": "string"}},
            "required": ["order_number"],
        },
    }
]


@app.post("/webhook")
async def inbound(req: Request, tasks: BackgroundTasks):
    body = await req.json()
    value = body["entry"][0]["changes"][0]["value"]

    if "messages" not in value:
        return {"ok": True}  # delivery status callback, not a message

    msg = value["messages"][0]
    if seen_before(msg["id"]):
        return {"ok": True}  # Meta retries; dedupe on message id

    tasks.add_task(handle_turn, msg)
    return {"ok": True}  # answer fast, think later


def handle_turn(msg):
    wa_id = msg["from"]
    touch_service_window(wa_id)
    history = load_window(wa_id, max_turns=8)
    reply = run_agent(history + [user_turn(msg)], tools=TOOLS)
    send_session_text(wa_id, reply)
    save_turn(wa_id, msg, reply)

How do you wire tool calls into a CRM?

Define every business action as a typed tool with a strict schema, execute it server-side, and feed the result back to the model as a tool result. The model decides which tool to call; it never decides what the data says.

This is the single biggest quality lever. A model asked to talk about orders will hallucinate an order. A model given a lookup_order tool will either call it or admit it cannot find the record. On ecommerce builds this is the difference between a bot that reduces tickets and one that creates them, which is why I lean on it heavily for ecommerce clients.

Where the CRM is GoHighLevel, HubSpot or a bespoke pipeline, the tool layer is just an authenticated HTTP client with retries and an idempotency key. I usually build it as a thin FastAPI service so the same tools serve WhatsApp, web chat and voice, which is the pattern behind AgentFlow. Keeping that layer transport-agnostic is what makes the queues and workers around it easy to reason about later.

When should the bot hand off to a human?

Hand off on explicit request, on detected frustration or complaint intent, on any money-moving action, and after two or three turns without resolution. Handoff is a feature, not a failure state, and it should be reachable in one message at any point.

The mechanics matter as much as the trigger. When a thread escalates, I set a paused flag on the contact so the webhook stops calling the model entirely, push the last several turns plus a one-paragraph summary into the agent's inbox, and post a single message telling the customer a human is coming and roughly when.

How much does an AI chatbot on WhatsApp cost to run?

Two independent bills: Meta's messaging charges and your LLM token spend. Meta moved to per-message pricing, where you are charged when an approved template is delivered, with rates varying by template category and country, while free-form replies inside the customer service window are not charged. Utility templates sent while that window is still open are also free, which is a real argument for resolving in-window rather than reopening later. Check Meta's official pricing page for current rates before you model anything.

LLM cost scales as tokens per turn multiplied by turns per conversation multiplied by conversation volume. The lever most teams ignore is the first factor. Halving your context window halves the bill without touching volume, and usually improves answer quality at the same time.

Routing is underrated. A classifier or a small model can resolve greetings, hours and order-status intents for a fraction of the cost of your best model, which then only sees the turns that need it. The full conversation-billing mechanics are broken down in the WhatsApp Business API pricing guide.

What breaks in production?

Duplicates, ordering and silence. Meta retries webhooks it thinks failed, users send three messages in six seconds, and your model occasionally takes twelve seconds to answer a question about opening hours.

If you are still deciding whether the Cloud API is the right surface at all, the Business API versus Business App comparison is the honest version of that decision. And if you would rather have this designed, built and handed over documented, that is what my WhatsApp Business API work and broader AI automation services exist for.