How to analyze possible impacts of the evolution of WhatsApp IDs on Builder/Studio flows

Index:

1. Overview
2. What changes in the variable format
3. How to run the analysis in Builder/Studio
4. Scenarios identified by the analysis
5. How to interpret the CSV report
6. What each criticality level means
7. Best practices
8. Limitations of the analysis
9. Do I need to fix my flows right now?
10. FAQ

Overview 

WhatsApp is evolving its user identification model with the introduction of Usernames and new identifiers. With this change, the phone number may no longer be shared automatically in some interactions. In this scenario, some Blip variables used in Builder/Studio flows may take on a new identifier format, no longer exclusively containing the phone number. 

To support the adaptation of the flows, we have made an automatic analysis feature available in Blip that identifies uses of the following variables:

• contact.identity 

• tunnel.originator 

• tunnel.identity 

Important: the analysis flags potential dependencies, but it does not necessarily mean that the flow will break. The main risk lies in operations that assume these variables will always contain a phone number.

What changes in the variable format 

Currently, these variables return the identifier in the following format:

5599999990002@wa.gw.msging.net 

As of June 1, 2026, and in cases where the user's phone number is not shared by Meta, the format will become:

e4b11bdd-a9bf-46ad-a9b0-34116dece5fe@wa.gw.msging.net 

Flows that extract the phone number directly from this value - for example, via contact.identity.split("@")[0] - will need to be reviewed.

How to run the analysis in Builder/Studio 

The feature is available directly in the Builder/Studio, within the flow to be analyzed.

1. Access the Builder/Studio of the desired flow 

2. In the banner displayed at the top, click the Analyze flow link 

3. Wait for the automatic processing 

4. Review the blocks visually highlighted in the flow 

5. [Optional] Click Download report to get the detailed CSV

The highlighted blocks indicate that some action uses potentially impacted variables and requires validation and/or manual alteration. 

Note: if no block uses the analyzed variables, the banner will turn green, indicating that no action is required at the moment.

Scenarios identified by the analysis 

• The scan flags uses of the variables in contexts such as:

• Extraction of the phone number (e.g., split("@")[0]) 

• Custom scripts and HTTP calls 

• External integrations with CRMs, ERPs, and other systems that receive or store the value as a phone number 

• Parsing of identifiers and conditional rules 

• Storage of the identifier as an operational key in third-party systems

How to interpret the CSV report

The report available for download contains one line per identified action, with the following columns:

What each criticality level means

High 

Indicates high probability of dependence on the phone number. Generally associated with scripts, HTTP calls, parsing, or direct manipulation of the identifier. Priority review recommended.

Medium

Indicates operational or indirect use of the variables, such as storage, trackings, events, or intermediate variables. Necessary to validate the expected behavior.

Low 

Indicates low immediate risk of operational impact. Optional and preventive review.

Best practices 

• Treat contact.identity, tunnel.originator, and tunnel.identity as generic strings, do not assume that the value will always be a phone number 

• Review external integrations that consume these variables as a fixed identifier

Limitations of the analysis 

• The analysis DOES NOT replace the manual validation and correction of the flow 

• Some custom scenarios may not be detected automatically 

• The report represents the state of the flow at the moment the analysis was executed, changes are not reflected in the report automatically. Run the analysis again after changes for an updated report.

Do I need to fix my flows right now? 

Not necessarily. The impact occurs specifically in interactions with users who do not share their phone number, which happens when they adopt a username on WhatsApp. Users without a username will not be affected. 

The recommendation is to perform preventive validation of the flows, prioritizing those flagged with high criticality and keeping in mind that, according to Meta's schedule, the general availability of usernames should happen in all countries as early as August 2026.

FAQ 

My flow was flagged. Does this mean it will break? 

No. The analysis identifies potential dependencies that need to be validated manually. A flagged flow can function normally depending on how the variable is used. 

Does the analysis alter my flow automatically? 

No. The analysis is only a diagnostic tool. No block, script, variable, or integration is automatically altered by Blip. Evolutions need to be made manually by the person responsible for the flow. 

My flow was not flagged. Am I 100% prepared? 

Not necessarily. The analysis covers the main uses of variables within the Builder/Studio, but external integrations, databases, and connected systems must also be reviewed. 

Can I ignore the alerts? 

It depends on the implemented logic. It is recommended to review especially scripts, integrations, HTTP calls, and any use that assumes the phone as a fixed identifier.

Learn more 

• Usernames on WhatsApp: BSUID, new IDs, and impacts on Blip 

• Meta's official documentation on BSUIDs 

• Blip Academy - Usernames Track

Need more help? Explore our content at Blip Academy or Blip Community, watch tutorials on our YouTube channel, or clear your doubts in our service channel 😃