A WhatsApp phone number has always doubled as the customer's identity in every system built on top of it: your CRM, your inbox, your reporting. Meta's own documentation makes clear that assumption stops being safe in 2026.
What a business-scoped user ID actually is#
Per Meta's own documentation, "a BSUID is a unique user identifier that can be used to message a WhatsApp user when you don't know their phone number." The format is specific: the user's ISO 3166 alpha-2 country code, a period, then up to 128 alphanumeric characters -- for example, US.13491208655302741918. It identifies a WhatsApp user, and it's tied to a specific business, hence "business-scoped."
Why this exists: usernames are rolling out#
The reason BSUID exists at all is that "WhatsApp will start rolling out usernames gradually in 2026," per Meta. Once a user adopts a username, other people, including businesses, can find and message them by that username rather than a phone number. That is useful privacy for the end user. It is a real problem for any integration, CRM, or reporting system that was built assuming "phone number" and "customer identity" are the same field.
Meta's documentation is direct about the businesses side too: starting June 29, 2026, a business can adopt or change its own username through Meta Business Suite, WhatsApp Manager, the WhatsApp Business app, or the Username API, and reservation opened the same date. One detail worth getting right: adopting a business username does not hide the business's own phone number in the WhatsApp or WhatsApp Business client. A business username maps to a single phone number, one username per number, and no two WhatsApp numbers, business or personal, can share a username.
The timeline, as Meta documents it#
- Early April 2026: BSUID began appearing in webhook payloads.
- June 29, 2026: Businesses could begin reserving and adopting their own username, through Meta Business Suite, WhatsApp Manager, the WhatsApp Business app, or the Username API.
- July 2026: Meta's APIs added support for sending messages targeted directly at a BSUID, not just a phone number.
All three dates have already passed as of this writing. This isn't a "coming soon" feature to bookmark for later. If your integration hasn't been checked against BSUID, that check is overdue, not upcoming.
Why "required" means required#
Meta's documentation doesn't frame BSUID support as optional or best-practice. It states plainly: "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." The reasoning given is straightforward: "because you cannot control whether your users adopt usernames, you must support BSUID to avoid losing the ability to process their messages." If a customer adopts a username and your system can only look someone up by phone number, you risk losing the ability to identify or message that specific conversation thread correctly.
What to check with your provider or your own integration#
Whether you built your own WhatsApp integration or you run on a managed platform, this is worth a direct conversation:
- Does the inbound webhook payload get parsed for BSUID and username fields, not just
wa_idor phone number? Meta added these fields to standard messaging webhooks starting in April 2026, and to calling webhooks (Call Connect, Call Terminate) in the following changelog update. - Can your system send a message using only a BSUID, for cases where a phone number was never captured, particularly on click-to-WhatsApp ad-driven conversations?
- Does your CRM or contact model treat phone number as the sole unique key? If a contact record, a deduplication rule, or a reporting dashboard assumes one phone number equals one identity, a user who adopts a username without you tracking their BSUID correctly can create a duplicate or orphaned record.
This is exactly the kind of platform plumbing that should sit below the surface of a managed inbox, handled by whoever runs your WhatsApp API connection rather than something you personally re-implement. If you run your own integration or work with a smaller provider, it's worth confirming directly rather than assuming it's covered.
What doesn't change#
Your own business's phone number stays visible to customers even after you adopt a username; usernames are an additional identifier, not a replacement for the number your customers already have saved. And nothing about this changes how the 24-hour customer service window or template messaging rules work. It's specifically about how a user is identified, not how or when you're allowed to message them.
