What WhatsApp’s New BSUID Feature Means for Your Business

A major shift in how customers are identified on WhatsApp 

WhatsApp’s new business-scoped user ID (BSUID) marks an important change for businesses that use the WhatsApp Business API. As usernames roll out to end users in 2026, some customers will be able to contact businesses without sharing their phone numbers. Instead of relying only on a phone number (MSISDN) as the customer identifier, businesses will need to support BSUID as part of their messaging, routing, and customer data workflows. 

Phone numbers are not being removed; however, customers will now have more privacy options. When a customer chooses to use a username, businesses may see a BSUID in places where they previously expected a phone number.  

What changes technically when BSUID arrives 

From a technical perspective, BSUID changes what businesses can expect to receive in webhook payloads and what they must be able to send back in API requests. In practical terms, the identifier shown in sender and recipient fields may no longer always be a phone number. Depending on the scenario, your systems may receive a phone number, a BSUID, or both. That means any logic built around MSISDN-only assumptions—such as routing, contact matching, conversation history, attribution, or campaign targeting—needs to be reviewed and updated. 

BSUID is designed to be stable for the relationship between a specific customer and a specific business. In other words, the same customer can have a different BSUID with different businesses, but for your business, that identifier remains the one you should store and reuse for future interactions. Supporting this properly is essential if you want your integration to continue working seamlessly once more customers start using usernames instead of exposing their phone numbers. 

For clients using Chat Flow, in a flow expression, [[session:channelUserId]] will act as a generic catchall for BSUID and MSISDN. BSUID must be supported in all flows. 

Will there be any changes to OneAPI? 

Yes. The following changes are applicable: 

1. Sending Messages 

The `to` field now accepts either a phone number or a BSUID: 

``json 

// Sending to a phone number (unchanged) 

{ "to": "27835544524", "content": "Hello!" } 

// Sending to a BSUID (new) 
{ "to": "ZA.9373795779eb6441c8adb2eaee5b848e7dd174ddd302d7db62142f4722d574b6", "content": "Hello!" } 

```

There are no new fields to learn. It is the same `to` parameter, with a new accepted format. 

Note: Authentication templates (one-tap, zero-tap, copy-code) still require a phone number. Sending these to a BSUID returns error `Delivery Failure (23)`. 

2. Receiving Messages (Inbound Callbacks) 

Three new fields have been added to the `whatsapp` object in MO callbacks: 

The `from` field now contains: 

• The phone number (when available — as is currently done) 

• The BSUID (when the phone number is unavailable) 

Example:  User with username, no phone number available: 

{ 

 "from": "ZA.9373795779eb6441c8adb2eaee5b848e7dd174ddd302d7db62142f4722d574b6", 

 "to": "2799900002", 

 "content": "Does it come in blue?", 

 "whatsapp": { 

  "profileName": "Kerry Fisher", 

  "username": "@kerryfisher", 

  "userId": "ZA.9373795779eb6441c8adb2eaee5b848e7dd174ddd302d7db62142f4722d574b6" 

 } 

} 

Example: User with username, phone number still available: 

{ 

 "from": "27835544524", 

 "to": "2799900002", 

 "content": "Does it come in blue?", 

 "whatsapp": { 

  "profileName": "Kerry Fisher", 

  "username": "@kerryfisher", 

  "userId": "ZA.9373795779eb6441c8adb2eaee5b848e7dd174ddd302d7db62142f4722d574b6" 

 } 

} 

3. Status Callbacks 

No changes. Delivered/read/failed callbacks remain unchanged. 

💡Developer takeaway:  Build for both scenarios from the start. Some messages will include a phone number and a BSUID, while others may include only the BSUID. Systems that can gracefully handle both will be far better prepared for the rollout. 

💡Important information for developers: Business-Scoped User IDs — Meta for Developers 

Why CRM and customer data models need attention 

For many businesses, the most significant impact of BSUID will be in the CRM. If your customer records, chat histories, or automation flows rely on phone numbers as the primary key, then this update introduces a new reality: some customers may arrive without one. That makes it critical to rethink how identities are matched and how records are maintained over time. 

A practical approach is to treat BSUID as a primary identifier for WhatsApp interactions and then enrich customer records through in-conversation data capture or other approved linking methods. Historical chat history does not disappear, but businesses may need logic to merge or reconcile records if a customer later shares a phone number after initially interacting through a username. The key design principle is flexibility: your data model should support both identifiers, rather than assuming one will always be present.

How to prepare your integration before the rollout 

If Clickatell manages your integrations, we'll make the necessary changes to ensure that you're prepared for this update. Your TAM will get in touch with you if there is anything specific to your account. 

If you manage your own integrations, you will need to make sure that your systems are prepared. The below checklist can be used as a guide: 

• Audit every system that reads or writes a WhatsApp phone number. 

• Add a BSUID field to message, contact, and integration schemas. 

• Update routing, CRM linking, chat history, attribution, and campaign logic to support either identifier. 

• Review bots and automations that assume an MSISDN is always present. 

• Test sandbox and production-like scenarios before broader rollout milestones later in 2026. 

• Decide whether supporting contact-book style resolution features makes sense for your business model. 

Our TAMs and Support team are on standby to assist you, should you need it. 

How is Clickatell preparing for this change? 

Introducing: The Clickatell Contact Book 

Bridging BSUID and MSISDN — with consent at the core. 

We've heard the concern from many of you: "How do I keep my CRM, marketing attribution, and cross-channel identity working when half my customers go BSUID only?" That's why we're launching the Clickatell Contact Book — an optional, opt-in service for Chat Flow customers. 

What It Does 

Meta's BSUID model exists to give end users more privacy, and we respect that fully. The Contact Book is engineered as a consent-driven, legally bounded bridge. It does not bypass any WhatsApp privacy controls. It only resolves identifiers where consent and contractual obligations are satisfied.  

The Contact Book lets Chat Flow users resolve a BSUID back to its underlying MSISDN (where the customer has consented at the WhatsApp level), so that: 

• Existing CRM records keyed on phone numbers continue to match 

• Marketing attribution and campaign lists remain intact 

• Cross-channel identity (SMS + WhatsApp) stays unified 

• Chat history is not fragmented across identifiers 

• This is not a default service, and the following is required: 

• Formal customer opt-in by your business. 

• Signed Clickatell Contact Book Agreement by your authorized signatory. 

  • The agreement covers: 
    • Scope of data resolution and permitted use 
    • Data protection and privacy (GDPR, POPIA, CCPA where applicable) 
    • End-consumer consent obligations 
    • Liability and indemnification 
    • Data retention and deletion policies 

No BSUID resolution will occur on your account until both opt-in and the signed letter are complete. 

Want to discuss whether the Contact Book fits your use case? Reach out to your TAM today.