Before you hand your WhatsApp number to a vendor

Somewhere in most chat or AI onboarding calls there is a moment that sounds like an administrative detail. The vendor says: just give us your WhatsApp number, we will handle the Meta side. It is offered as a kindness, and usually it is one. The Meta side is genuinely tedious and the vendor has done it before.

It is also the most consequential decision in the whole engagement, and it tends to get made in about four seconds, by someone with no particular reason to think it matters.

Here is what is actually being decided, and what is worth asking before you answer.

It is not one thing, it is five

"Your WhatsApp" is at least five separate objects in Meta's world, and they get spoken about as though they were one:

• the business portfolio, the company's container inside Meta;
• the WhatsApp Business Account (WABA), which represents the business on the platform and owns the numbers, the message templates, the quality state and the payment method;
• the phone number itself, which lives inside a WABA and carries the display name, quality rating and messaging limit;
• the vendor's app, the integration, with its credentials and webhooks;
• and a system user token, the machine identity the vendor's server authenticates as.

Only some of these should belong to the vendor. The app and the token are theirs, and should be: that is the software. The portfolio, the account and the number are the clinic's business identity on a channel patients use, and where they get created is permanent.

The line that decides everything

Meta's own documentation is blunt about it. A WABA belongs to a single business portfolio, cannot be migrated between businesses, and cannot be owned by two at once.

Read that again with the onboarding call in mind. If the vendor creates the account inside their portfolio with the clinic's number in it, that account is theirs. Not contractually, structurally. There is no later administrative step that hands it across, however amicable the parting or however carefully the contract was written.

Everything else here follows from that one sentence. I have written before about the checks a build should pass before it earns write access to a live system. This is the same instinct pointed at ownership rather than code: work out what is reversible before you grant it, not after.

What the clinic keeps, and what it does not

Start with the reassuring part. Patients notice nothing. The chat thread on a patient's phone follows the number, whoever operates it behind the scenes. Continuity on the patient's side is free, and no vendor can hold it hostage.

The clinic's own side is a different story.

The conversations are the lock-in, not the number. Meta's Cloud API does not keep a retrievable message history for you to go and fetch later. Every transcript of every patient conversation exists in exactly one place: the vendor's database, behind the vendor's inbox product. If the contract does not compel a data export, leaving means losing all of it. Not migrating it, losing it. For a clinic that is the record of what patients were told about preparation, prices and availability, which is exactly the material you want when a question comes back three months later. An assistant is only trustworthy if you can go back and read what it actually said, and you cannot do that with records you do not hold.

Templates, quality history and billing sit on the account, not with you. Approved message templates, the display name and its review, the quality rating, the messaging limit, the payment method and the invoice history all attach to the WABA or to the number inside it. In a vendor-held setup the clinic's number also sits in a portfolio alongside other businesses' numbers. Ratings are per number, but Meta does not document, either way, whether a portfolio-level enforcement problem can reach neighbouring accounts. That is not a proven risk. It is an undocumented one, and you would be accepting it on someone else's behalf.

The number can leave, but not on its own

Numbers are the one asset with a real migration path, so a vendor saying "you can always take your number with you" is telling the truth. The mechanics are where it gets interesting.

Migrating a number into a new WABA is initiated by the destination owner, and it requires two-step verification to be switched off on the source account. The source account is the incumbent's. So the exit route runs through the cooperation of the vendor you are leaving, at the moment you are leaving them. There are further prerequisites on both sides: business verification approved on each, a display name in approved status with no pending change, a payment method configured on the destination, webhooks subscribed. One number at a time. There is no bulk move.

If it does go ahead, the display name, quality rating, messaging limit and Official Business Account status survive, and registration is instant, so messaging does not stop. But only previously approved high-quality templates duplicate. Low-quality, rejected and pending ones do not, and template quality ratings reset. Meanwhile the onboarding that was skipped at the start, portfolio, verification, account, payment method, now has to happen under time pressure in the middle of a separation.

That is the real cost. Not a bill. A dependency, discovered late.

Five questions for the onboarding call

None of these are hostile. A vendor with a clean answer gives it in a sentence.

1. Whose business portfolio will the WhatsApp Business Account be created in, ours or yours? Everything else is downstream of this one.
2. Will anyone from our side log in to Meta during setup? This is the useful discriminator, because it is observable rather than asserted. If the account is genuinely being created under the clinic's portfolio, somebody at the clinic has to authenticate to Meta at some point. If the number is handed over and nobody on your side ever sees a Meta login screen, the account is the vendor's.
3. Where do the patient conversations live, and what do we get back if we leave? Ask for the export to be named in the contract, in a format a successor could actually use.
4. If we leave, what do you have to do for our number to move? A straight answer names the two-step verification step and the destination prerequisites. A breezy "of course, it is your number" has not engaged with the mechanics.
5. Who does Meta bill? Payment method and invoice history sit on the account. If the vendor is billed and re-invoices you, that is one more thing you do not hold.

A sixth, if the answer to the first was "ours": some Meta user identifiers are scoped to a business portfolio. Whether that affects how a future provider could link a returning patient to their earlier history is not documented anywhere I can find, so it is worth asking rather than assuming.

The honest version of the trade-off

None of this makes the vendor-held model dishonest. It is genuinely lower friction, clinics like it, and plenty of good work gets delivered that way. The problem is the shape of it: the friction it removes is front-loaded and the cost it creates is deferred, and the person clicking through the onboarding call is rarely the person who eventually pays it.

The alternative is not more work for the clinic. It is more work for the vendor. The account gets created inside the clinic's own portfolio, verified against the clinic's own entity, and the vendor is added as a partner who can be un-assigned in a click. Exit stops being a negotiation: the clinic keeps the portfolio, the account, the number, the display name and the quality history, and the vendor keeps the software, which was always the part worth keeping.

If you are being onboarded by anyone this month, ask question two. It takes ten seconds, and it tells you most of what the other four would.