An employee's personal phone rings all day with business calls that came in through WhatsApp, because that is the only device those calls can reach. A WhatsApp call placed through the Business app can only ring the single device the business's WhatsApp number lives on, which is why every inbound call lands on the same phone instead of being distributed the way every other business call is.
Why Every WhatsApp Call Rings the Same Phone
On the WhatsApp Business app, an inbound call rings the single device the business's WhatsApp lives on. Ten calls come in, and all ten land on that same phone: no queue, no distribution, no fallback to a second person while the first is already on a call. One employee absorbs the whole load while the rest of a team, and the phone system built to handle exactly this kind of volume, sits untouched.
The reason usually given is that the call connects client to client, peer to peer, directly from the customer's phone to the one phone the business WhatsApp number lives on. A peer-to-peer call needs a peer on the other end, and on this setup there is only one.
Moving to the Cloud API Removes the Button Entirely
Businesses that move from the WhatsApp Business app to the Cloud API, often as an upgrade to solve exactly the volume and integration problems above, run into a second surprise: the inbound call button disappears. The commonly cited reason is that the Cloud API connection is client to cloud rather than client to client. Once there is no single device the number is tied to, there is nothing for an inbound call to terminate on, so WhatsApp does not offer the button on that connection type.
A business that moves to the Cloud API for good reasons can lose inbound WhatsApp calling entirely without anyone deciding to switch it off. It is not a setting that got missed. The capability simply is not there on that connection type.
Getting the Button Back, Routed Into the Real Phone System
A SIP connection to Meta gives the call somewhere to terminate again. The call reaches a SIP server and forwards from there into whatever the business already runs for inbound calls: a PBX, an IVR, a hunt group, a queue. The customer never leaves WhatsApp to place the call. What changes is where it lands afterward.
| Setup | Where the call lands | Queue, distribution, fallback |
|---|---|---|
| WhatsApp Business app | The single device the WhatsApp number lives on | None |
| Cloud API, no SIP connection | Nowhere - the call button is not available | Not applicable |
| Cloud API with a SIP connection to Meta | The business's existing phone system: PBX, IVR, hunt group, or queue | Whatever the business already runs |
What This Actually Costs a Business
The cost is not the calls that get answered. It is the ones stacked up behind the one call already in progress, on a phone with no queue to hold them. Picture ten calls arriving in the time it takes to handle one: nine callers are either waiting on a ring with no system behind it, or hanging up and trying elsewhere. That is an illustration, not a measured figure, but it is the shape of what happens when a single personal phone is standing in for a whole phone system.
How Wappari Routes These Calls
Wappari holds a SIP connection with Meta to solve exactly this. Because Wappari sits in telephony as well as messaging, an inbound WhatsApp call rings through to wherever a business already answers calls today: the same queue, the same rules, the same people already trained to handle it. The customer keeps using WhatsApp exactly as before. What changes is invisible to them and entirely visible to the team receiving the call.
If your business runs inbound voice on WhatsApp, it is worth checking which of the three setups above you are actually running today, and whether an upgrade you already made quietly removed a capability nobody flagged as gone.