A number stopped working: how to find out why
When a connected number stops working, the cause is almost never the code. Work through it in order of frequency: an expired token, a webhook override lost to a reconnection, a fourteen day inactivity disconnection, a quality drop, then an account restriction.
- Ordered by what actually happens
- The app keeps working through all of it
- Each has a distinct signal
Nothing charged for 7 days. Cancel anytime.
Causes that account for nearly every silent failure.
The error an expired token returns, which looks like a missing number.
The event that reports a disconnection authoritatively.
Why does nothing look wrong on the phone?
Because the WhatsApp Business app and the API are separate surfaces on the same number, and almost every failure affects only one of them.
A token expires and the app is untouched. A webhook override is uninstalled and the app is untouched. Quality drops and the app is untouched. In every case the business continues answering customers, sees normal behaviour, and has no reason to report anything.
This is the entire argument for monitoring rather than for a dashboard somebody checks. The failures are real, they are silent, and the people closest to the number are the least likely to notice them.
What order should you check in?
Start with the token, because it is the most common and the cheapest to fix. An expired or invalidated credential makes every call fail identically, which looks exactly like the number having been removed. Holding a second credential against the same account is what tells the two apart.
Then the webhook override. If a reconnection happened, the destination was uninstalled with the app, so sending and monitoring work while delivery to your server silently does not.
Then a disconnection: an account_update event with PARTNER_REMOVED and a reason, where PRIMARY_INACTIVITY means the app went unopened for around fourteen days and reconnecting fixes it.
Then quality, which is polled rather than pushed, and finally a restriction, which is an account level enforcement no provider can lift.
What is almost never the cause?
Your code, if it was working yesterday and nothing was deployed.
The Cloud API is stable and its request shapes do not change underneath you. When an integration that ran for months stops, the overwhelming likelihood is a credential, a routing change or an account level event, all of which happen without anyone touching a repository.
The exception worth naming is a template that was edited. Changing the number of variables in a template changes the contract for every sender, silently, and that does look like a code fault while being a content change made in WhatsApp Manager by somebody else.
Common mistakes
- Reconnecting the number first. If a token expired, that asks the business owner to do work that was never needed.
- Assuming the code broke. A stable API plus no deploy points elsewhere.
- Checking the phone for symptoms. The app keeps working through nearly every one of these.
EasyCoexistence checks all five continuously and records each on the connection timeline, so troubleshooting starts from a dated event rather than from a guess.
Frequently asked questions
The number works on the phone but nothing sends. Where do I start?
The access token. It is the most common cause and the one that most resembles a removed number.
I reconnected and messages still are not reaching my server.
The webhook override was uninstalled with the app. It has to be reapplied; we do it automatically.
How do I know if it was the fourteen day rule?
The disconnection arrives with reason PRIMARY_INACTIVITY on the account_update event.
Could a template edit break my sends?
Yes, and it is the one cause that resembles a code fault. Changing variable count changes the contract for every sender.
Keep reading
Ready to get started?
Set up WhatsApp Coexistence in minutes, not months. The app keeps working on the phone.
Start Free TrialNothing charged for 7 days. Cancel anytime.Verified on