Why WhatsApp hides a customer's phone number, and what can still be recovered

If you run WhatsApp through a QR-paired integration, you may have noticed something that looks like a bug and is not: some contacts arrive with no phone number at all. The inbox shows a name or an opaque identifier, the CRM record is created without a phone field, and no amount of reconnecting changes it.

This is WhatsApp migrating accounts to LID addressing, and the reason it is worth 1,500 words is that almost everything written about it is wrong in one of two directions: either “it is a bug in your integration” or “re-pair the number and it will come back”. Neither is true, and the second one costs real customers real time.

What a LID is

WhatsApp is moving one-to-one chats from phone-number addressing to an opaque per-account identifier. Once a chat has moved, the peer’s messages arrive addressed to a LID — a 14- or 15-digit number that identifies the person within that account’s view and is not their phone number.

That overlap is the single most dangerous property of the whole thing. An integration that infers “15 digits, starts with a plausible country code, therefore a phone number” will cheerfully store one — and the number it stores belongs to nobody.

It is per account, not per contact and not per date

We measured this on one customer’s portal, on one day, through one build. Five WhatsApp numbers, all paired the same way, all running the same code:

number	one-to-one chats	LID-addressed	phone-addressed	new that day	new that were LID
A	41	41	0	7	7
B	179	179	0	45	45
C	104	8	96	7	0
D	164	4	160	0	0

Two numbers are 100% LID-addressed including every new chat that day. Two are 96% and 98% phone-addressed and took zero hidden chats. Same application, same code path, same customers, same hours.

The only variable is the WhatsApp account. Grouping the chats by creation date shows the two populations running side by side, every single day, which kills the “it is a gradual rollout by date” theory outright.

Re-pairing does not reverse it, and we know because we tried

This is the part worth paying attention to, because it is a recommendation we made and then had to withdraw.

Three numbers on that portal were disconnected and re-linked by QR, on the strength of advice that re-pairing clears stale state. We verified the re-pair happened at the credential level rather than from a timestamp — the stored authentication state was wiped and rebuilt, which is what a genuine pairing does and what a mere reconnect does not.

Twenty minutes after a fresh QR scan, one number was still 31 of 31 chats LID-addressed and another 102 of 102. One of them has never held a single phone-addressed conversation in its entire history.

The flag lives at WhatsApp. There is no local state that influences it, so there is no local action that changes it.

The half that can be recovered, and the half that cannot

Here is where the usual write-ups stop, and where the useful part begins.

The phone number is frequently on the stanza even when the chat is LID-addressed: WhatsApp supplies it as a sender attribute on the wire. On the two worst-affected numbers we counted, of 247 and 135 undeliverable inbound messages, 129 and 62 carried both the LID and a phone number. Across 48 hours, 116 distinct peers appeared whose number we could have learned and had not.

So for a large fraction of hidden contacts the number is recoverable — not by asking WhatsApp again, but by reading what it already sent and keeping it.

What is not recoverable is the rest. Fifteen of 71 decryption failures in one sample carried no phone number in any attribute. Those peers are unaddressable by any mapping, and no integration can produce a number WhatsApp does not supply.

Why this matters for a CRM

Two consequences, and the second is the expensive one.

A hidden contact cannot be the target of automation. If a workflow is supposed to message the person a record belongs to, and the record has no phone number, the honest outcome is a refusal that says so. The dishonest outcome is an integration that reconstructs a plausible number from the identifier it does have — which, given the digit-length overlap above, means messaging a stranger.

A contact can become visible later, and the record has to catch up. When a number does arrive on a later message, the contact is promoted — and the CRM record created earlier without a phone field needs the number pushed into it. That is a backfill, and it only works if the earlier identifier was stored as an identifier rather than guessed at as a phone number.

The one transport where this does not happen

The official WhatsApp Cloud API returns the customer’s phone number properly. That is not a marketing point, it is a structural difference: the Cloud API is Meta’s own interface and delivers the contact’s wa_id, whereas a QR-paired connection is a companion device and sees what WhatsApp chooses to show a companion device.

If hidden contacts are a problem for your business — because your CRM, your dialler or your automation needs the number — that is a genuine argument for the Business Platform, independent of any compliance argument.

And “hidden” is becoming the normal case rather than the exception. The two numbers in the table above that are still mostly phone-addressed are simply not migrated yet. Their contacts will start arriving hidden on WhatsApp’s schedule, with nothing on an integrator’s side triggering or deferring it.

A measurement note

Every figure above is a count from a production database, on named dates, on one customer’s estate. We publish them because the usual version of this article has no numbers in it at all, and a claim about how common something is cannot be evaluated without one.

Two things we got wrong on the way, in case you are debugging the same thing:

• “No matching sessions found for message” does not mean “no session”. For all 16 affected peers in one sample we held two session records, not zero. An investigation that checked three peers, found none, and concluded a mapping was missing nearly shipped a dependency upgrade on the strength of it. Count the population before believing the mechanism.
• A loss that does not decay is not a drifting ratchet. Our inbound loss was flat across a restart. Something that is healing decays; something being re-created by every reply does not. That distinction is what pointed at addressing rather than at encryption.