It was a Friday night when I found out.
Two of my clients' WhatsApp numbers had gone quiet. Not "delayed" quiet — dead quiet. No inbound, no outbound, nothing moving through the API. By the time I traced it back, the answer was the kind you don't want at midnight on a Friday: the Business Solution Provider those numbers lived on had gone into administration. No email, no deprecation notice, no wind-down window. One day it was routing messages; the next it wasn't a company anymore.
If you're reading this because the same thing just happened to you — take a breath. I got both numbers migrated and messaging again. This is the whole path, including the one dead end that will eat your first night if nobody tells you about it.
I'm writing it the way I wish someone had written it for me at 1 a.m.
01 — The diagnosisFirst, understand what actually broke
When a BSP disappears, your instinct is that "WhatsApp is down." It isn't. WhatsApp, Meta, and your phone numbers are all fine. What broke is the connection between your numbers and the messaging API — the BSP was the middleman holding that plumbing together, and the middleman left.
The number itself, the WhatsApp Business Account (WABA) it lives in, the templates, the verification — in my case all of that still existed on Meta's side. The problem is narrower and more annoying than "everything is gone." It's this: to move a number from a dead BSP to a live one, you have to get past a security lock that the dead BSP set up and never handed you the key to.
That lock is two-step verification — a 6-digit PIN attached to the number. And here's the trap: the BSP configured it during onboarding, the PIN was theirs, and now there's nobody at that company to ask for it.
That single PIN is the entire problem. Everything below is about getting around it — legitimately.
02 — Before you panicInterrogate the dead BSP's API while it still answers
Here's the first thing almost nobody thinks to do, and it decides everything that comes after.
A company going into administration does not mean its servers switch off that same day. In my case, the BSP's API kept answering requests for a while after the company itself was gone. If you still have your API key from when you were a customer, you can query your accounts directly and read the single most important field in this whole ordeal: who owns the WABA.
Most BSPs expose an accounts endpoint under their Cloud API. The shape is usually something like:
bashcurl -s "https://api.tyntec.com/conversations/v3/channels/whatsapp/accounts/<ACCOUNT_ID>" \
-H 'accept: application/json' \
-H 'apikey: YOUR_API_KEY'
In the JSON that comes back, look for the ownership field. In my case the key was ownershipType, and the value that saved me was:
json"ownershipType": "CLIENT_OWNED"
This is the fork in the road. Read it carefully, because the two branches are very different nights:
The WABA belongs to your client (or you), not to the dead BSP. This is the good branch — you can fix the 2FA yourself, tonight, without waiting on anyone. Keep reading.
The dead BSP owned the asset. The hard branch — you can't self-serve; you'll need Meta to intervene. Skip to section 05.
If the dead BSP's API is already offline and you can't check, you can often still see ownership from Meta's side in Business Settings / WhatsApp Manager, under your Business Manager. But check it however you can before you start — it tells you which of the two guides below is yours.
03 — The trapThe myth that will waste your first night
Before the fix, let me kill the idea you're probably already having.
You'll think: "I control the physical phone line. I'll just re-register the number on a new provider with an SMS or voice code, and that bypasses the old PIN."
It does not. I asked Meta support this exact question — I had full control of the phone lines and offered to do SMS or voice verification. The answer was explicit: physical access to the line does not bypass two-step verification. As long as 2FA is active on the number, you cannot register it under a new provider, no matter how many verification codes you can receive.
The lock isn't on the line. It's on the number's 2FA setting — and that's what has to come off first. Trying to brute-force re-verification is the single biggest time-sink of the first night.
04 — The fixCLIENT_OWNED: the client turns off 2FA themselves
This is the part that feels almost too simple after the panic. If the WABA is client-owned, the 2FA setting lives in a place your client can reach — their own WhatsApp Manager — and the dead BSP is irrelevant to it.
Meta support confirmed this path to me directly: they can't reset the PIN manually (for security reasons, they have no manual override), but the owner of a client-owned WABA can simply disable two-step verification from their own account. The dead BSP is not in the loop for this.
Here's the click path. The account owner — your client, logged into their Business account — does this:
- Go to business.facebook.com/settings/ and log in to the Business account that manages the WABA.
- Open WhatsApp Accounts. Find and click the WABA.
- In the WABA info panel, click Settings.
- In the new tab, open WhatsApp Manager.
- Find the phone number and click its Settings.
- Open Two-step verification and turn it off.
That's it. Once 2FA is disabled on the number, the lock is gone and the number is free to be registered somewhere new.
If the toggle asks for the current PIN before letting you disable it, you're stuck — that PIN is the one the dead BSP set, and nobody has it. In my case it let the owner disable it without demanding the old PIN, and that's what made the self-serve path work. If yours demands the old PIN, you've effectively fallen onto the hard branch below.
The last step: re-register on your new provider
With 2FA off, the number is portable again. On your new provider — I moved mine onto the WhatsApp Cloud API through my own Tech Provider setup — you register the number the normal way and set a fresh 2FA PIN of your own during that registration.
That new PIN matters: it's yours now, you control it, and you'll never be locked out by a third party again. Write it down somewhere you actually own. The entire crisis you just lived through was, at its root, a PIN held by someone else — don't recreate that dependency.
Once registered, send a test message end to end. When it goes through, you're migrated.
05 — The hard branchIf the WABA isn't client-owned
If ownership came back as anything other than client-owned, the self-serve toggle isn't available to you, because the asset belonged to the dead BSP. You'll need to escalate to Meta directly and ask for a two-step-verification reset on the grounds that the provider is defunct and unreachable.
Open a case through Meta Business support, explain that the BSP is in administration with no one able to disable 2FA, and provide the WABA and Business Manager details for the numbers. Be patient and be precise — have your ownership evidence and your Business Manager IDs ready before you open the case. This branch is slower and depends on Meta, but it is a path. It's just not the fast one.
06 — In hindsightWhat I'd tell my Friday-night self
Three things, in order:
- Nothing is gone. Your number, your WABA, your templates — they're on Meta, not on the BSP. The BSP only held the connection.
- Check ownership first.
CLIENT_OWNEDmeans you can fix it tonight. Anything else means you're waiting on Meta. Everything downstream depends on that one field. - The PIN is the whole game. You're not fighting WhatsApp; you're removing one lock the old provider left behind. Once it's off and you set your own, you're free.
The reason a dead provider could take two of my clients offline overnight is the same reason it was fixable: the numbers and the accounts were genuinely the clients', sitting on Meta's infrastructure, with the BSP as a replaceable layer on top. That's the whole argument for owning your WABA and connecting as directly as you can — so the next time a vendor disappears, it's an afternoon of work, not an existential event.