Create a WhatsApp chatbot: prepare the number connection

Want to create a WhatsApp chatbot without losing days on number-related problems? The good news is that preparation boils down to three decisions: which number, under which ownership status, and in which WhatsApp Business mode. The bad news is that these decisions shape everything that follows: reconnecting a poorly prepared number often costs more than starting clean.

This article covers only preparing the number connection, not dialogue design or message templates. We will cover prerequisites, the three official modes, the difference between transport authentication, provider authorization and operational proof, then a concrete acceptance plan. If you then move on to the agent itself, the guide on WhatsApp AI agents for customer requests picks up on the conversation side.

Why number preparation decides the whole project

A WhatsApp chatbot is not a script running on a phone. It relies on a connection between your number and a technical layer that sends and receives messages. If that connection is poorly prepared, symptoms appear later: messages going out on the wrong channel, inability to test, a number locked by reckless reconnection attempts.

Preparation answers three separate questions. Who owns the number and its associated Business status? Which official mode is used? And who can, at which level, authenticate the connection and prove that a message actually travelled? These three questions are independent: confusing them can lead to an incorrect connection diagnosis.

A useful framing point: transport connection, provider authorization and operational proof are three different things. Transport is the pipe between the number and the platform. Authorization is the right to use that pipe in the company's name. Proof is a message identifier or a delivery status that attests a message was sent. A successful connection proves neither authorization nor operation.

Prerequisites on the number and owner side

Before any technical handling, gather the administrative elements. They determine what you will be able to do without a painful migration.

• A dedicated number if possible. A number already used by the consumer WhatsApp app or the WhatsApp Business app carries constraints: it cannot serve two incompatible uses simultaneously, and some migrations are irreversible. A number dedicated to the chatbot avoids these conflicts.
• An identified owner. The Business account belongs to an entity, not to whoever happens to be around. Define who is administrator, who can revoke, and who receives alerts. A number whose only holder is a provider that disappears is a classic trap.
• A consistent display name and category. They will be visible to your customers and contribute to trust in the channel.
• A decision about history. Keeping existing conversations or starting from scratch: this choice influences the possible connection mode.

Also check the channel's usage compliance: the WhatsApp Business usage policy sets obligations on consent, message quality and prohibited uses. This is not a formality: a number reported for unsolicited messages sees its quality drop, and quality conditions what the channel will let you do next. Our article on WhatsApp Business automation, consent and templates covers that side, which should be thought through before the connection, not after.

The three modes: app, Platform, possible coexistence

WhatsApp offers several ways to connect a number, and the choice matters.

The WhatsApp Business app suits manual usage: one or two people answering, possibly helped by quick replies. It provides no programmable interface for a chatbot. If your goal is an agent that answers automatically, this mode is only a transitional step.

The WhatsApp Business Platform (formerly Cloud API) is the mode suited to creating a chatbot. The number becomes a resource managed through a programming interface, with credential-based authentication, webhooks to receive messages and calls to send them. This is the mode that lets you orchestrate an agent, log exchanges and integrate your business tools.

Coexistence is a specific regime: in some eligibility cases, a number can stay active on the app while being connected to the Platform. Do not assume you qualify: eligibility depends on the number's state, the device and usage history, and it is verified by official mechanisms, not by your wish. When in doubt, assume a number dedicated to the Platform is the simplest path.

Starting situation	Recommended mode	Why
New number, never used on WhatsApp	Business Platform	No usage conflict, clean connection
Existing Business app, manual replies only	Business app	No automation needed
Business app, automation wanted	Migration to Platform	The app does not allow a chatbot
Consumer number with history to keep	Study coexistence if eligible	Otherwise migration with history loss
Several teams, several numbers	Platform with dedicated number per use	Isolation of permissions and proofs

Transport authentication, provider and permissions: three levels to distinguish

This is where many projects look for the wrong proof. Distinguish three levels.

Transport authentication establishes that your system can talk to the platform: credentials, tokens, webhook configuration. It answers the question "does the pipe work?".

Provider authorization concerns the Business account itself: who may administer the number, add webhook recipients, submit message templates. This is account-level access control, separate from the technical token. A token can be valid while the person who obtained it no longer has the required rights.

Operational permissions determine what your chatbot may do once connected: reply to an incoming message, send an approved template, access an internal tool. This is the same principle as for any agent connected to your tools: our AI agent permissions checklist offers a decision grid that applies as-is here. The general lesson holds for every connector: a label or a checked box is not a permission boundary; application-level controls are what actually limit behaviour.

Concretely, record for each level: who holds the credentials, where they are stored, who can renew them, and which log records every send. These notes will become your recovery plan.

What the QR code proves — and does not

Scan a QR code and the app shows "device connected". Many conclude their number is wired to the Business Platform. That is wrong, and the confusion is costly.

The QR code associates your number with a device or client within the app ecosystem. It proves an active session at that level, nothing more. It does not prove an official Business Platform connection exists, provides no message identifier usable by your chatbot, and delivers no webhook. An agent "connected" only via a QR code has neither reliable transport for automated use nor operational proof.

Operational proof on the Platform side is something else: a message identifier returned at send time, delivery statuses received via webhook, a call log. When a customer disputes an appointment or a confirmation, that identifier is what counts, not a screenshot of the app. Demand this proof systematically in your tests — we come back to it in the acceptance plan.

The same vigilance applies on the integration-tools side: a catalogue of available actions depends on the tool used and the connected account. What appears in a tool list is not therefore active, authorized or tested on your number. Always verify on your own environment.

Step-by-step preparation procedure

Here is a preparation procedure you can follow in order. It assumes you are targeting the Business Platform.

1. Inventory the number. Where is it used today? Who receives the verification SMS? Are there conversations to preserve? Write the answers down.
2. Designate the owner and roles. One Business account administrator, one technical lead, one alert recipient. Three people can be the same, but the role must be named.
3. Choose the mode. App, Platform, or coexistence if eligibility is confirmed by official mechanisms. When in doubt, Platform with a dedicated number.
4. Prepare message reception. Set up a reachable reception point (webhook) and check it responds correctly before connecting the number.
5. Connect the number and authenticate transport. Generate credentials, store them in a secrets manager, note their expiry date.
6. Verify provider authorization. Confirm the Business account shows the right owner and that roles match step 2.
7. Run a test send with proof. Send a message, retrieve the message identifier and delivery status. Archive them.
8. Document reconnection. Write down what to do if a session is lost, and who is authorized to do it.

This procedure does not replace your provider's official documentation; it structures it and makes it verifiable.

Main example: the Santé-Plus clinic (fictional scenario)

Let's take a fictional case to illustrate the decisions. Santé-Plus, a two-site clinic, wants a WhatsApp chatbot that confirms appointments and answers practical questions. Three numbers exist: the secretariat's consumer number, in use for years; a WhatsApp Business app number installed on an assistant's phone; and a fax line that has become useless.

The trap would have been to hook up the secretariat number "quickly" via a QR code. The first time the assistant's phone fails, the chatbot goes down, and nobody knows how to restore the connection. Instead, here are the decisions:

• The fax number becomes the chatbot's dedicated number: no conversations to preserve, no usage conflict.
• The director owns the Business account; the technical lead holds the credentials; the assistant receives quality alerts.
• The chosen mode is the Business Platform, with a webhook into the appointment management system.
• Every appointment confirmation sends a message whose identifier is stored in the internal patient record. In case of dispute, the clinic proves the send without depending on a phone.

The key takeaway: the structuring decision was not technical but organizational — separating the chatbot's number from the human number. Sensitive conversations stay with the secretariat, and automation runs on a channel that can be reset without disrupting the teams. For the next stage of the project — triaging incoming requests, escalating to a human — the guide on organising customer requests with a WhatsApp AI agent naturally extends this example.

Reconnection, revocation and the acceptance plan

A connection lives: sessions expire, phones change, credentials rotate, a provider leaves. Prepare for these events before they happen.

Reconnection. Document the restoration procedure with the same requirements as the initial connection: owner verification, transport authentication, test send with proof. A reconnection without a test send is not a successful reconnection.

Revocation. Define who may revoke access, in which cases (departure, incident, suspected compromise), and how credentials are replaced. Revocation must be possible without reinstalling anything on the customer side.

Acceptance plan. Before declaring the chatbot connected, run a written checklist:

• an incoming message triggers the webhook, with an acknowledgement from your system;
• an outgoing message returns a usable message identifier;
• a delivery status is received and logged;
• revoking a credential actually blocks sends;
• the reconnection procedure has been replayed by someone who did not write the documentation.

The last point is the most often neglected. Our article on chatbot development, from acceptance testing to handover stresses this principle: an acceptance plan only has value if someone other than its author can replay it.

Limits, common mistakes and what to do

Three mistakes recur, and each has a simple remedy.

Confusing session and connection. An active app session is not a Platform connection. What to do: accept only message identifiers and webhooks as proof, never an app screen. Assuming features. Coexistence, interactive flows, catalogues: not all are available in every case. What to do: verify your number's actual eligibility before building on a feature, and plan a fallback without it. Neglecting channel exit. Plan from the start how a customer leaves the automated channel: a human message, an unsubscribe, an escalation. The WhatsApp Business usage policy and core data protection principles — purpose limitation, minimization, individual rights — apply to conversations processed by your agent. These reminders are design guidelines, not proof of compliance: have your processing validated by the competent people in your organization.

Finally, on cost: Business Platform pricing depends on market and message category, and not all messages are paid in the same way. Do not build a business model on a price heard here or there; check the platform's official pricing page and project your own volumes, including the scenario where incoming conversations reopen service windows.

If you would like to frame your number connection and then build the agent that goes with it, you can define a mission on Edeverse's offers page.

Frequently asked questions

Can I use my current WhatsApp Business number for a chatbot?

It is possible in some cases, but it usually implies a migration to the Platform, with constraints depending on the number's history. The simplest path remains a dedicated number. Assess what you would lose if the conversation history could not be kept.

Is the QR code enough to connect my chatbot?

No. The QR code establishes an app-level session, not an official Business Platform connection. Without message identifiers or webhooks, your agent has neither reliable transport nor operational proof. Demand these elements before considering the connection established.

What if the connection drops on a weekend?

That is exactly what pre-written reconnection documentation is for: who intervenes, with which access, and which test validates the restoration. Add a human-side fallback message to inform customers during the outage.

How do I prove a message was actually sent to a customer?

Through the message identifier returned at send time and the delivery statuses received via webhook, archived in your system. A screenshot of the app is not usable proof, because it does not tie the send to your Business account in a verifiable way.

Do I need one number per chatbot, or can several share one?

One number per automated use is safer: isolation of permissions, proofs and sending quality. Sharing a number between human replies and an agent is possible under some coexistence regimes, subject to official eligibility, but it complicates reconnection and accountability.