Potential Impact of WhatsApp Usernames (BSUID) on Workflows
Updated
WhatsApp usernames can change the identifiers included in incoming webhooks. In most scenarios, the webhook will continue to include both the phone number and the BSUID. However, in a narrow edge case, the first inbound message from a new user may contain only the BSUID.
What this means for your integration
Once available, when a customer adopts a username and messages a business for the first time, Cloud API will return the BSUID with no phone number.
Initial Impact is limited: This change primarily affects new customer-initiated messages from username adopters when the customer has never messaged that business before.
Business as usual: Existing contacts, conversations, and workflows are unaffected. Phone numbers continue to be included if:
Contact Book is enabled (default).
There has been recent interaction (within 30 days).
You can still send messages, place calls, or request the phone number in‑thread using the Phone Number Request CTA.
What changes in incoming webhooks?
When the relevant conditions are not met, an incoming webhook may provide the user’s BSUID instead of their phone number.
Phone numbers are expected when:
The business has messaged or called the user within the last 30 days (for example, after sending an HSM).
The user is present in Meta’s business contact book, which includes users who interacted with the business after the contact‑book feature was enabled.
If neither condition applies:
The first inbound message from a user with an enabled username may contain only the BSUID.
Subsequent messages may include the phone number once interaction is established.
Client workflows that are not expected to be impacted
CRM import followed by outbound messaging: A client imports a profile into Sprinklr using the phone number and sends an HSM or another message. If the user replies, the recent outbound interaction means the phone number should remain available in the incoming webhook.
Existing contacts with recent activity: Two-way conversations remain linked through the existing phone-number and BSUID information when there has been an inbound or outbound interaction within the last 30 days.
Contacts retained in Meta’s contact book: Even if the profile was not previously created in Sprinklr, the webhook may include both identifiers, allowing Sprinklr to create or merge the profile from a subsequent message.
Client workflows that may be impacted
Inbound-first from an unknown user: A user with an enabled username sends the first message, the client has no prior interaction, and the user is not in Meta’s contact book. The webhook may contain only the BSUID, so Sprinklr may not be able to match the message to a CRM profile by phone number.
Dormant contacts: A profile was imported into Sprinklr long ago, but neither the business nor the user has interacted within the last 30 days and the contact is not retained in Meta’s contact book.
First-message automation: Automation that depends on the phone number being available on the very first inbound webhook may fail to identify the existing profile or select the correct next action.
Potential operational impact in Sprinklr
The inbound message may not associate with the existing WhatsApp conversation or profile when only the BSUID is available.
Sprinklr may create a separate channel profile instead of merging with the existing phone-number profile.
This can result in duplicate profiles, fragmented conversation history, and loss of context for agents and downstream automation.
Profile creation or merging may become possible when a later webhook includes both the phone number and BSUID, but the first message may already have been processed separately.
Expected impact window and likelihood
This is considered a minor edge case rather than a broad workflow change. The main exposure occurs with the first inbound message from a previously inactive or unknown user, while the standard CRM import and outbound HSM workflow remains unaffected. A short transition window of roughly two weeks during the initial rollout period may require closer monitoring, particularly for businesses whose users frequently initiate conversations.
Recommended mitigations and next steps
Validate which client workflows depend on phone-number matching on the first inbound webhook.
Continue using outbound HSM or other permitted messaging where appropriate to establish a recent interaction before expecting replies.
Ensure webhook and profile-matching logic stores both the BSUID and phone number and can update a profile when the phone number becomes available later.
Monitor duplicate profiles, unstitched conversations, and BSUID-only inbound events during rollout.
Review dormant CRM contacts and prioritise appropriate re-engagement or data-validation strategies.
Communicate the narrow impact clearly to clients: the main risk is an inbound-first conversation from an unknown or inactive user, not the standard CRM import followed by outbound messaging.