For as long as businesses have used WhatsApp, one number did every job. The customer's phone number was the address you messaged, the key your CRM matched on, the join column in your data warehouse and the row your consent record hung from. Meta has now taken those jobs apart. WhatsApp users can adopt a username and keep their phone number private, and businesses on the WhatsApp Business Platform receive a different identifier in its place: a business-scoped user ID, or BSUID.
The change, by the numbers
This is not an optional developer detail. Meta's own documentation states that "supporting business-scoped user IDs (BSUID) is required for all partners and directly-integrated businesses on the WhatsApp Business Platform — as well as CTWA advertisers." It changes who you can recognise on the channel most of your customers already use, and the window in which you can still see a phone number is measured in days, not quarters.
Poin-poin penting
WhatsApp opened username reservation on 29 June 2026 and is rolling the feature out gradually, country by country, with adoption optional for users and businesses alike. A username lets someone start a chat without handing over a phone number. There is no directory to browse, so the other party has to know the exact handle, and WhatsApp adds an optional username key that a stranger must also know before a first message goes through.
Because a username adopter's number is hidden, Meta needs to give your integration something stable to identify that person with. That is the BSUID. It arrives in the webhook payload alongside the phone number when the number is available, and on its own when it is not. Which of the three situations below you are in decides what your systems actually see.
Meta defines a BSUID as "a unique user identifier that can be used to message a WhatsApp user when you don't know their phone number." It is generated automatically. You do not request one, and there is no migration to run. The table below is the whole specification that matters for a production integration.
| Property | What Meta specifies |
|---|---|
| Format | The user's ISO 3166 alpha-2 country code, a period, then up to 128 alphanumeric characters — for example US.13491208655302741918 |
| Scope | Unique to your business portfolio. The same customer carries a different BSUID at every other business, and a BSUID issued to one portfolio cannot be used to message from another |
| Stability | Stable for that customer, but regenerated if they change phone number. Two webhooks fire: a system message with user_changed_user_id, and a user_id_update webhook carrying both the previous dan current BSUID |
| Where it appears | Yang user_id property in the contacts block of every messages webhook, recipient_user_id in the statuses block, and parent_user_id if you have enrolled in parent BSUIDs |
| What accepts it | The Messages, Marketing Messages, Calling, Groups and Block Users APIs, from July 2026 |
| What rejects it | One-tap, zero-tap and copy-code authentication templates, which still require a phone number |
A BSUID is deliberately scoped so that two businesses cannot compare notes and work out that they are talking to the same person. If you run several WhatsApp Business Accounts and phone numbers under one business portfolio, they share the customer's BSUID. If your group holds separate portfolios, they do not — and passing a BSUID across that boundary fails. Agencies and holding groups managing several client portfolios can enrol in parent BSUIDs, which issue a shared identifier usable by any business phone number inside the enrolled set.
Once the feature is enabled for a customer, their username appears in incoming messages webhooks and in delivered and read status webhooks. Treat it as a display value, not a key. Customers can change a username; the BSUID is the thing you match on. Meta documents exactly two recipient identifiers for sending — a phone number and a BSUID — so a username is something a customer types to reach you, not something you can send to. And a customer's username has nothing to do with your own WhatsApp Business display name, which is unchanged by any of this.
Worth stating plainly, because it is easy to miss in the documentation: Meta writes that "supporting business-scoped user IDs (BSUID) is required for all partners and directly-integrated businesses on the WhatsApp Business Platform — as well as CTWA advertisers." If you run Click-to-WhatsApp campaigns, you are in scope whether or not you think of yourself as having an integration.
The honest answer is that the blast radius is small but badly placed. Nothing in your outbound template programme changes. What changes is the moment a new customer starts a conversation — which is exactly where your CRM does its matching. Meta names Click-to-WhatsApp advertisers explicitly among those required to support BSUIDs, so paid acquisition sits squarely inside the affected path.
| Flow | Customer without a username | Customer with a username |
|---|---|---|
| New inbound service message | Phone number and BSUID | BSUID only, unless the 30-day rule or your Contact Book applies |
| Click-to-WhatsApp ad conversation | Phone number and BSUID | BSUID only, on the same conditions |
| Reply inside an open service window | Unchanged | Unchanged |
| Utility or marketing template to a number you hold | Unchanged | Unchanged where you hold the number |
| One-tap, zero-tap or copy-code authentication | Unchanged | Phone number required — a BSUID is not accepted |
| First outbound message to someone new | Phone number | BSUID, from July 2026 |
No endpoint returns an error when a BSUID-only conversation arrives. Your webhook receives a valid payload; it simply has no phone number in it. A contact lookup keyed on phone number returns nothing, so a well-behaved system does the reasonable thing and creates a new contact. The customer's history, consent state, tags, open tickets and lifetime value stay attached to the old record. Nobody notices until an agent asks a returning customer to repeat themselves, or a suppression list fails to suppress.
That risk compounds anywhere the phone number is the join key downstream: helpdesk tickets, data warehouse tables, marketing suppression lists, consent registers and the audit exports that regulated firms rely on. If you run WhatsApp in a supervised environment — a brokerage under SFC record-keeping expectations, or a bank under HKMA supervision — a split customer record is not merely untidy. Our note on record-keeping for brokerages covers what that obligation looks like in practice.
It is easy to read the announcements and conclude this is a 2027 problem. It is not. The identifier has been arriving in your webhooks since April 2026; only customer adoption is gradual.
| When | What happened | What it means for you |
|---|---|---|
| Early April 2026 | BSUIDs began appearing in webhooks, for every customer, whether or not they have a username | The data is already in your logs. You can map existing customers to their BSUIDs today, before adoption starts |
| 29 June 2026 | Businesses could begin reserving a username through Meta Business Suite, WhatsApp Manager, the WhatsApp Business app or the Username API | Your handle is a brand asset. Claim it before someone else does |
| July 2026 | Meta's APIs began accepting a BSUID as the message recipient | You can reply to and re-engage a customer you have no phone number for |
| Through 2026 | WhatsApp rolls usernames out to users gradually, country by country | Adoption in your markets is the variable to watch. The plumbing should already be finished |
The sequencing is a gift, and most teams are not using it. Between April and the moment usernames become common in Hong Kong, Singapore and Malaysia, every inbound message carries both identifiers. That is a free mapping exercise: capture the pair now, and when a customer later hides their number, you already know who they are.
The single highest-value change is unglamorous: add a field. Everything else follows from having somewhere to put the identifier.
| # | Change | Who owns it | Done when |
|---|---|---|---|
| 1 | Add a BSUID field to the contact record in your CRM, helpdesk and data warehouse. Keep the phone number — you need both | CRM or RevOps owner | The field exists, is indexed, and is populated by new inbound traffic |
| 2 | Update webhook parsing to read user_id, and contact matching to try BSUID first, then phone number. Add a handler for the user_id_update webhook so a regenerated BSUID overwrites the old one instead of creating a second record | Integration owner | A test message from a username-adopting account resolves to the right record, and a simulated user_id_update updates it in place |
| 3 | Backfill. Every inbound message between April 2026 and today carried both identifiers — replay your logs and attach BSUIDs to existing contacts | Data owner | Your active book has BSUIDs against it |
| 4 | Add the REQUEST_CONTACT_INFO button to the flows that genuinely need a phone number — delivery, onboarding, callbacks — instead of asking an agent to type it out | Automation owner | The button is live on the templates that need it |
| 5 | Brief agents and bot teams. A contact with no phone number is now normal, not a data error to be fixed manually | Service lead | Your playbook says so in writing |
Meta hosts a Contact Book for each business, with no integration work required. Once you send a message or call to a phone number, or receive one from it, the number and the BSUID are recorded together, and that mapping is then used to populate future webhook payloads with the phone number. Numbers can also be added manually, or added when a customer taps the share-contact button. In practice, the Contact Book means your existing, actively-messaged book is largely protected even after those customers adopt usernames.
Second, there is a REQUEST_CONTACT_INFO button type that can sit on utility and
marketing templates or be sent as an interactive message. When the customer taps it, their phone
number is shared into the thread. That is the sanctioned way to ask for a number when a workflow
genuinely requires one — a courier hand-off, an identity check, a callback — rather than
harvesting numbers by habit.
If your inbound volume runs through several channels, the same discipline applies beyond WhatsApp: a contact record that survives an identifier change is the point of an integrated CRM in the first place. Teams still deciding how they connect to WhatsApp at all should start with the difference between the app, the API and the Platform and, if they are choosing a hosting model, with Cloud API versus on-premises.
It is tempting to read a BSUID as an anonymisation win: fewer phone numbers in your database, less to lose in a breach. That reading is half right and worth being careful with.
A BSUID identifies one individual within your business's context, and it is the key you use to reach them. Under Hong Kong's Personal Data (Privacy) Ordinance (Cap. 486) and the guidance the PCPD publishes around it, and under Singapore's Personal Data Protection Act administered by the PDPC, the safe working assumption is that the same handling applies to a BSUID as to a phone number: purpose limitation, retention limits, access control, and a deletion path that actually deletes. The same logic holds under the GDPR, where pseudonymised data remains personal data. This article is general information rather than legal advice; your own counsel should confirm how these obligations apply to your organisation.
There is a genuine upside, though, and it is worth naming. Storing a BSUID instead of a phone number for customers you have never called reduces the sensitivity of what sits in your systems. Institutions answering to the HKMA, the SFC or Singapore's regulators can point to that as a data-minimisation improvement rather than a new exposure — provided the identifier is governed with the same rigour as anything else in the customer record, under an information-security programme aligned to a recognised standard such as ISO/IEC 27001.
Opt-in rules are unchanged. What changes is what the opt-in record points at. If your consent register is keyed on phone number alone, a customer who later hides their number can look unconsented, or worse, look like a fresh contact with no history. Store both identifiers against the consent event, with a timestamp and the source, and the register survives the transition. This is worth doing before your next campaign, not after.
The commercial half of this update gets less attention than it deserves. A WhatsApp username is a
short, memorable, typeable address for your business — the difference between printing a
15-digit number on a shopfront and printing a handle. Businesses have been able to reserve one since
29 June 2026 through Meta Business Suite, WhatsApp Manager, the WhatsApp Business app or the Username
API, and creators and organisations can claim a handle matching an existing Instagram or Facebook
username. If yours is contested or unavailable, WhatsApp publishes
troubleshooting guidance for business
usernames. A business_username_updates webhook fires whenever your username status
changes to reserved, approved or deleted, so you can alert someone rather than discover a lapse by
accident. One caveat worth stating plainly: a username is not a messaging address. Meta documents a
phone number and a BSUID as the recipient identifiers, so you reach customers by those, not by
their handle.
Teams already running WhatsApp at scale in the region will find the operating context in our guides to WhatsApp Business API pricing in Hong Kong, the API in Singapore and WhatsApp for banks across APAC. If you are also experimenting with group conversations, the same identity rules apply to the WhatsApp Groups API.
Not sure whether your setup already stores BSUIDs?
imBee is an Official Meta Technology Partner supporting 10,000+ enterprises across 60+ industries in Hong Kong, Macau, Taiwan, Singapore, Malaysia, Indonesia and the Philippines. Talk to our team about how your WhatsApp Business Platform account and CRM handle the change.
The questions below are the ones that come up first when a team reads the Meta documentation for the first time.
BSUID stands for business-scoped user ID. It is a unique identifier Meta issues for each WhatsApp user within the context of a single business portfolio, so a business can recognise and message that customer even when it does not have their phone number. It arrives in the webhook payload of every inbound message.
No, and conflating them causes most of the confusion. A username is the public handle a customer chooses and shares, and they can change it. A BSUID is a machine identifier your integration receives, unique to your business portfolio, which the customer never sees. Match records on the BSUID; treat the username as a display value.
Not for most of your book. Phone numbers keep arriving for every customer who has not adopted a username, for anyone you exchanged a message or call with in the last 30 days, and for anyone already recorded in your Meta-hosted Contact Book. You lose the number only for new conversations with username adopters you do not already know.
Yes, and now is the cheapest moment. Between early April 2026 and the point usernames become common in your market, every inbound message carries both a phone number and a BSUID. Capturing that pair today builds your mapping for free. Waiting until adoption starts means backfilling against incomplete data.
No. Meta documents exactly two recipient identifiers: a phone number and, since July 2026, a BSUID, accepted by the Messages, Marketing Messages, Calling, Groups and Block Users APIs. A username is what a customer types to reach you, not an address you can send to. One-tap, zero-tap and copy-code authentication templates still require a phone number.
Business username reservation opened on 29 June 2026. You can adopt or change a business username in Meta Business Suite, WhatsApp Manager, the WhatsApp Business app, or through the Username API. Creators, businesses and organisations can claim a handle matching an existing Instagram or Facebook username.
It is stable for a given customer within your business portfolio, with one exception: it is regenerated if the customer changes their phone number. Two webhooks fire when that happens, a system message carrying user_changed_user_id and a user_id_update webhook carrying both the previous and current BSUID. Handle the latter so the new identifier overwrites the old one.
Treat it as personal data. A BSUID identifies one individual within your business's context and is the key you use to reach them, so the prudent position under Hong Kong's Cap. 486 and Singapore's PDPA is to apply the same purpose limitation, retention and deletion rules you apply to a phone number. Confirm the specifics with your own advisers.
Rollout dates and API behaviour are as documented by Meta at the time of writing and are subject to change. Verify against Meta's documentation before you build.
Kelly S.
Content Team Lead, imBee
Kelly S. owns content strategy, product positioning, and customer education at imBee. Previously, Kelly led B2B SaaS content programs and supported go-to-market initiatives for customer engagement products. On the imBee blog, Kelly covers conversational commerce, omnichannel messaging, WhatsApp Business, customer experience, and strategies for scaling business communications.
Questions about anything in this article? Talk to our team.
Discuss your channels, team and conversation handover needs in a product demo.
