Meta is replacing the identity key
The phone number has always been how you identify a WhatsApp user. Meta is replacing it, and the replacement has been landing in your webhooks for months.
Users can now adopt a username, so other people see @name instead of their number. Adoption is optional and gradual, and you have no say in who opts in.
A user who adopts one gets phone number privacy, and their number stops arriving in your webhooks. So Meta introduced an identifier that doesn't depend on the phone number, and issues one for every user.
This is already happening, across everything Kapso processes:
On August 2, 0.46% of the messages Kapso received arrived with no phone number, against 0.00% on July 28. An integration that looks customers up by phone number can't match any of them. Updated daily.
What replaces the phone number
The business-scoped user ID, or BSUID. It looks like this:
US.13491208655302741918An ISO 3166 two-letter country code, a period, then up to 128 alphanumeric characters. Meta generates it automatically.
BSUIDs are already in your webhooks, for every user, including the ones who will never adopt a username. The two features arrived together but they're independent: the username removes the phone number, the BSUID replaces it.
| Field | When it arrives |
|---|---|
user_id | Always, since April 2026. |
username | Only if the user adopted one. |
wa_id / from | Unless the user has a username, is outside the 30-day window, and isn't in your contact book. |
Two phases, and where we are
Meta ran this as an additive phase followed by a subtractive one. Nothing broke on the way in.
| When | What happened |
|---|---|
| April 2026 | BSUIDs start appearing in every messages webhook, alongside the phone number. Purely additive. |
| June 2026 | Businesses can reserve and claim their own username. |
| July 2026 | The send APIs accept a BSUID as recipient, and the button for requesting a phone number ships. |
| Now | Users adopt usernames gradually. For some of them the phone number has already stopped arriving, and that share grows. |
The new identifiers landed months ago, and nothing forced anyone to read them, so most integrations didn't. The removal is what's starting now, and it happens per customer rather than on a fixed date.
It's also partial. Plenty of messages still carry a phone number, and for customers you've spoken to in the last 30 days it keeps arriving even after they adopt a username. What's changed is that the share without one is no longer negligible, and it grows week over week.
While both identifiers arrive for a customer, you can map one to the other. Once a customer's phone number stops arriving, that mapping can no longer be built.
This isn't optional
Meta requires BSUID support across the WhatsApp Business Platform, and the identifiers reach your systems whether you integrate with Meta directly or through a provider like Kapso. You can't control whether your customers adopt usernames, and if one does and your integration can't process a message without a phone number, you lose the message.
Meta is explicit that there's no recourse. If a webhook arrives that your system can't process, there's no corrective action and no replay.
How much of this is yours to do
Four things break as this rolls out: reading a payload that no longer has the field you keyed on, storing an identifier that isn't globally unique, matching it to a customer you already have, and addressing a message to someone whose phone number you never learned.
How many of those land on you comes down to two questions, whoever you send through. Do you keep your own copy of the customer, or do you read them from your provider when you need them? And do you choose the identifier when you send, or do you hand over a conversation and let the provider choose?
The more your provider stores and resolves on your behalf, the less of this you have to build. Where that line falls is specific to each one, so check it against yours.
Where the line falls on Kapso
Kapso answers both questions on the data it holds, so the split is:
| Your setup | Chapters that apply |
|---|---|
| Your team answers in the inbox, and you read contacts and conversations from Kapso when you need them | 0.1 and 0.2 |
| You mirror customers into your own database or CRM | plus 1.1 and 1.2 |
You address sends yourself, through the Meta proxy or by setting to on the API, instead of sending by conversation or contact | plus 2.1 |
| You need a phone number for one-time passcodes, delivery calls, or a system you don't control | plus 2.2 |
The first two chapters are for everyone, because the identifiers arrive the same way whatever you do with them afterwards. Chapter 2.3 is a checklist to work through against your own integration.