Gupshup, BSUID, and Usernames: What Changes in WhatsApp Business in June 2026

The WhatsApp Business transition to BSUID and usernames is no longer an abstract roadmap topic. Starting June 29, 2026, Meta moved forward with the phase in which businesses can explore, reserve, and set corporate usernames on WhatsApp Business. At the same time, infrastructure providers such as Gupshup are offering compatibility layers to reduce the impact on integrations that still treat the phone number as the primary identifier.

If you are still getting familiar with the topic, start here: BSUID is the business-scoped user identifier. It lets a company recognize and reply to a person on WhatsApp even when the phone number is not available. Usernames move WhatsApp toward a model in which a user can start a conversation without exposing their number.

Gupshup's update adds a practical layer to this change: instead of forcing every partner to rebuild integrations immediately, the platform promises to resolve identity across BSUID, phone number, and username whenever possible.

What Gupshup is promising

The central promise is business continuity. Gupshup created an identity layer so companies can choose between two paths:

1. Enable BSUID support now and start receiving the new identifier in flows.
2. Keep operating with phone numbers while the platform resolves identity behind the scenes.

In practice, the change does not need to be treated as a big-bang migration. Companies with legacy systems, rigid CRMs, or bots that depend on phone numbers can gain time. But time is not permission to ignore the shift. It is a window to prepare data, reporting, automation, and human support for a world where the phone number becomes conditional.

Gupshup's public documentation on Username / Business-Scoped User ID confirms this direction: BSUID uniquely identifies a user within a business portfolio and can be used to message a WhatsApp user when the business does not know their phone number.

The BSUID feature toggle

The most relevant capability is the BSUID toggle API, or feature toggle. If BSUID is enabled, Gupshup sends the BSUID together with the phone number while that number is available. As Meta makes end-user usernames available, that combination may shift to BSUID + username or, in some scenarios, only BSUID + username.

If BSUID is disabled, the promise is that no immediate action is needed: Gupshup continues sending phone numbers whenever it can resolve them.

That sounds simple, but the decision affects architecture:

• Enabling BSUID early helps your company enrich CRM records and test deduplication before real volume grows.
• Keeping BSUID disabled reduces immediate change, but can hide dangerous phone-number dependencies.
• A mature operation should enable BSUID in a controlled environment, measure impact, and then release it to production.

The mistake is treating the toggle as a "turn it on later" button. The earlier your base captures BSUIDs, the lower the chance of duplicate contacts when conversations arrive without phone numbers.

Gupshup's Identity Graph

The most important concept in the update is the Identity Graph. Gupshup says it maintains a mapping repository between BSUID and phone number from the beginning of BSUID generation, using inbound and outbound WhatsApp interactions.

In practical terms, the platform tries to answer a critical question for every message: "do I know the phone number behind this BSUID?"

When it does, Gupshup associates phone and BSUID and preserves the experience for legacy integrations. When it does not, the message may arrive only with BSUID, or be handled in a special flow until identity is resolved.

This is especially relevant for organic entry points such as:

• QR Codes.
• wa.me links.
• Click-to-WhatsApp ads.
• Conversations started by users who adopted usernames.
• New customers who never interacted with the company before.

For commercial operations, this is the highest-risk area. The lead may exist and want to talk to you, but not bring the field your CRM has always expected as the key: the phone number.

What parked messages are

The brief uses "parked" messages to describe messages that Gupshup stores when the phone number is not available in the Identity Graph.

The logic is: if the platform cannot resolve the phone number immediately, it retains those messages securely for up to 30 days. A configuration API, still described as upcoming in the brief, will allow partners to retrieve those retained messages within that window.

This has two implications:

1. Your operation may avoid immediate message loss in no-phone scenarios.
2. Retention does not replace an architecture that is ready for BSUID.

A parked message is a safety net, not a customer service strategy. If your sales team depends on fast replies to ad-generated leads, every minute of retention or pending identity resolution has a cost. The goal should be to minimize cases where a legitimate conversation waits for identity.

Business usernames after June 29

The second phase of the update covers business usernames. Businesses can explore Meta suggestions, reserve a suggested username or request another one, track approval, and set the approved username.

For the brand, the benefit is clear: a username improves discovery and reduces friction. Instead of depending only on a phone number, QR Code, or phone-based link, the company can work with an identifier that is more memorable and consistent with Instagram, Facebook, and campaign channels.

But there is an important distinction: a business username does not by itself fix your CRM adaptation. It improves how customers find the company. BSUID solves technical user identity in the relationship with the company.

They are three parts of the same movement:

• Business username: how customers find the brand.
• End-user username: how customers can talk without revealing phone numbers.
• BSUID: how the API keeps a stable technical identity in that relationship.

Campaign sending to BSUID

Another operational point is campaign sending using BSUID. Gupshup's brief indicates that even when sending to BSUID is possible, the Identity Graph will try to use the phone number whenever it is available. Only when the number does not exist will the message be sent to the BSUID.

This behavior reduces change for known bases, but requires attention in three areas:

Consent. BSUID does not remove opt-in, customer care window, or template rules. If the contact arrived without a phone number, active messaging policy still applies.

Attribution. Campaigns and ads that match WhatsApp to CRM records must accept BSUID as the primary identifier in some cases.

Reporting. Dashboards that group conversations by phone number can break or create duplicates. The better model is reporting by canonical contact, with phone and BSUID as linked identifiers.

Proactive phone number collection

Meta provides a template that lets businesses request the customer's phone number when it is required. Gupshup recommends that partners create and send this template through existing APIs or as an interactive message.

The principle is simple: phone number stops being automatically available data and becomes data requested with context.

This is healthier for privacy, but changes the experience. You should ask for a phone number only when it is truly needed, such as authentication, delivery, billing, legacy-system integration, or follow-up through another channel.

For ordinary support, BSUID may be enough. Forcing phone collection in every flow can reduce conversion and feel misaligned with Meta's own privacy direction.

What your company should do now

If your operation uses Gupshup or any BSP that abstracts Meta's API, the action plan should be pragmatic:

1. Confirm the BSUID toggle state.
Ask whether it is enabled, in which environment, which fields appear in webhooks, and how this changes v2 and v3 payloads.

2. Integrate business username APIs.
Reserve or request the company's username and monitor approval status. Do not postpone this until competitors or third parties start competing for brand-adjacent names.

3. Update CRM for hybrid identity.
A contact should not be only a phone number. The minimum model needs phone, bsuid, username, and an internal canonical key.

4. Review bots and automations.
Any flow that does lookup assuming from is a phone number must accept BSUID. That includes triage, qualification, authentication, enrichment, and routing.

5. Define a parked-message policy.
If messages can be retained for up to 30 days, who monitors that? How does the operation retrieve them? Under which SLAs? What happens with paid-media leads?

6. Train human support teams.
A contact without a phone number is not necessarily suspicious or incomplete. It may simply be a customer using a username.

Tolky's role in this transition

For companies running support, sales, and customer service on WhatsApp, the risk is not only in the webhook. It is in the entire chain: CRM, queues, AI agents, reporting, campaigns, deduplication, and data governance.

Tolky treats the BSUID transition as an identity architecture change, not as a single field adjustment. In a prepared operation, the customer's history remains unified whether the conversation arrives with BSUID, phone number, or username. The AI can consult the correct contact, preserve context, and request additional data only when the process truly requires it.

Gupshup's update is a good signal for the ecosystem: providers are trying to absorb complexity to preserve continuity. But the strategic responsibility still belongs to the company. If your business depends on WhatsApp for revenue, support, or relationships, now is the moment to treat identity as critical infrastructure.

---

The phone number has not disappeared. It remains important, especially for known bases and authentication cases. But it is no longer a universal guarantee. From now on, mature operations need to think of identity as a set: phone number, BSUID, username, consent, and history.

Teams that make this transition calmly will barely feel the change. Teams that wait for the first lead without a phone number to discover the problem will meet the worst kind of backlog: real conversations trapped inside an old assumption.