Durante anos, o número de telefone foi a coisa mais estável da sua operação de WhatsApp. Ele era a chave. Cada cliente era, no fundo, um número no formato internacional E.164 — e tudo se pendurava nele: o cadastro no CRM, o histórico de conversas, as automações de campanha, a régua de relacionamento, os relatórios. Essa estabilidade está prestes a acabar. Em junho de 2026, a Meta iniciou o rollout de usernames no WhatsApp — identificadores que podem ocultar o número de telefone por padrão — e introduziu o BSUID, um novo identificador entregue às empresas via webhooks. Para qualquer operação que usa o telefone como chave de identidade do cliente, isso não é um detalhe técnico. É uma mudança estrutural.
A boa notícia é que não se trata de um apocalipse. A má notícia é que quem não entender o que está mudando vai descobrir o problema do jeito mais doloroso: vendo webhooks chegarem com um identificador que o CRM não reconhece, automações disparando para o cliente errado, e o histórico de relacionamento "sumindo" porque a chave que amarrava tudo deixou de bater. Este artigo explica o que são usernames e BSUID, por que o telefone deixa de ser confiável como identidade, e o que fazer para atravessar a transição sem quebrar a operação.
O que são usernames e BSUID no WhatsApp
São duas mudanças relacionadas, mas distintas. A primeira, o username, é voltada ao usuário final: a Meta passa a permitir que as pessoas tenham um nome de usuário — um @ — e, com isso, possam interagir sem expor o número de telefone. Na prática, o número deixa de ser necessariamente visível ou compartilhado. Para o consumidor, é privacidade. Para a empresa que dependia de capturar esse número, é uma fonte de identidade que pode simplesmente não estar mais disponível.
A segunda mudança é o BSUID — business-scoped user ID, ou identificador de usuário com escopo de negócio. É um identificador que a Meta entrega à empresa via webhooks para representar aquele cliente, mas com uma característica crucial: ele tem escopo no negócio. Ou seja, é um identificador estável para a relação entre aquele cliente e aquela empresa específica — não um número universal que você pode cruzar livremente com outras bases. O BSUID resolve o problema de identidade para a Meta e para a privacidade do usuário, mas transfere para a empresa a tarefa de reconciliar esse novo identificador com tudo que ela já tinha amarrado no telefone.
Por que o telefone deixa de ser a chave de identidade
O modelo mental que a maioria das operações construiu é simples: telefone igual a pessoa. Cada interação no WhatsApp vinha carimbada com o E.164, e esse número servia como identificador único e permanente para casar a conversa com o cadastro. Era confiável porque o número era estável e sempre presente. Essa premissa está sendo desfeita por design. Com usernames, o número pode não ser exposto. Com o BSUID, o identificador que chega nos eventos passa a ser outro. O telefone deixa de ser garantido como chave.
Isso muda a arquitetura da identidade. Em vez de um único identificador universal (o número) que servia para tudo, a operação passa a lidar com identificadores com escopo e potencialmente múltiplos atributos de identidade que precisam ser reconciliados. Quem trata identidade como "o número do cliente" vai ter um buraco. Quem trata identidade como uma camada — um perfil de cliente que pode ser referenciado por diferentes identificadores ao longo do tempo — atravessa a mudança sem perder histórico. A diferença não é de esforço heroico; é de onde você resolve o problema na arquitetura.
O risco real: webhooks com ID novo que não bate com o CRM
O ponto onde isso vira dor concreta é o webhook. Hoje, quando um cliente manda uma mensagem, seu sistema recebe um evento com o número e usa esse número para encontrar o cliente no CRM, recuperar o histórico e seguir a automação. No novo cenário, esse evento passa a carregar o BSUID. Se a sua base inteira está indexada por telefone e nada está preparado para o BSUID, acontece o pior tipo de falha silenciosa: o webhook chega, o sistema não encontra correspondência, e ou cria um contato duplicado, ou trata um cliente conhecido como desconhecido, ou dispara a automação errada.
O efeito cascata é grave. Campanhas segmentadas perdem precisão porque a segmentação não reconhece mais o cliente. Relatórios de relacionamento ficam fragmentados entre o "cliente antigo" (por telefone) e o "cliente novo" (por BSUID), que na verdade são a mesma pessoa. Integrações com ERP e CRM que assumiam o telefone como chave estrangeira começam a falhar nas bordas. E nada disso aparece com um erro vermelho óbvio — aparece como métricas que pioram sem explicação clara, até alguém investigar e descobrir que a chave de identidade mudou debaixo dos pés.
Como preparar contatos, automações e integrações
A preparação tem uma lógica central: desacoplar a identidade do número. Em vez de o número ser o cliente, o número passa a ser um atributo de um perfil de cliente que tem seu próprio identificador interno estável. A partir daí, você associa a esse perfil tanto o telefone (quando disponível) quanto o BSUID, e qualquer identificador futuro. Quando um webhook chega com BSUID, o sistema resolve para o perfil correto; quando chega com telefone, idem. O histórico fica preservado porque está ancorado no perfil, não na chave externa.
Concretamente, isso significa: revisar o modelo de dados de contatos para suportar múltiplos identificadores por perfil; ajustar a lógica de reconciliação no recebimento de webhooks para mapear BSUID a perfis existentes; garantir que as integrações com CRM e ERP sincronizem o novo identificador sem quebrar as chaves existentes; e validar que webhooks recebidos são autênticos — porque identidade desacoplada exige que você confie na origem dos eventos. Empresas que tratam webhooks assinados (com HMAC) e identidade como parte da arquitetura, e não como gambiarra de integração, fazem essa transição como um ajuste planejado, não como um incêndio.
O que uma plataforma enterprise já resolve por você
A diferença entre passar por essa mudança com tranquilidade ou com dor depende em boa parte da plataforma que está por baixo da sua operação de WhatsApp. Uma integração caseira, montada às pressas em cima do número de telefone, vai exigir um retrabalho significativo. Uma plataforma enterprise pensada para identidade desacoplada e webhooks confiáveis já tem o terreno preparado para a transição.
Como a CCX ajuda
É exatamente para esse tipo de mudança estrutural que o CCX Message foi desenhado. Como plataforma WhatsApp Business enterprise, oficial via Meta Cloud API, ele trata identidade e contatos na camada certa e recebe eventos por webhooks bidirecionais assinados com HMAC — o que significa que a operação já está preparada para reconciliar a transição do E.164 para o BSUID sem que o cliente "suma" do CRM. Multi-número, multi-organização e inbox conversacional multi-operador completam uma base que não depende do telefone como chave única.
Para sincronizar o novo identificador com os sistemas internos sem quebrar a base existente, entra a frente de Integrações & APIs Enterprise da CCX — conectividade event-driven com CRM, ERP e os demais sistemas onde o cliente vive, de modo que o BSUID se acomode na arquitetura em vez de explodir nela. O resultado é uma operação que continua reconhecendo o cliente mesmo quando o número desaparece da equação.
Quando o WhatsApp esconder o número, sua automação ainda reconhece o cliente? O CCX Message já trata identidade via webhooks assinados e está pronto para a transição E.164 → BSUID. Conhecer CCX Message →