O número de telefone sempre foi o centro de tudo no WhatsApp. Para o usuário, era o ponto de entrada. Para quem opera atendimento, vendas e cobrança, virou muito mais: sustentava cadastros, históricos, bots e integração com CRM. A Meta mudou isso com a chegada dos usernames e do BSUID (Business-Scoped User ID, ou ID de Usuário com Escopo de Negócio).
Com eles, o número deixa de ser o único identificador disponível na plataforma. Isso afeta como desenvolvedores recebem dados nos webhooks, como times de vendas e cobrança identificam contatos e como operações de marketing disparam campanhas.
Em bots, filas e históricos de atendimento no WhatsApp, a operação sempre se apoiou no número de telefone. Ele identifica o contato, puxa o histórico e alimenta o CRM.
Quando um usuário adota um @nome e a plataforma não está preparada, o bot pode não reconhecer o contato, o histórico some e o agente assume o atendimento sem contexto. Mensagens de resposta automática podem não ser entregues e leads que chegam via anúncio podem ficar sem retorno, tudo isso sem que nenhum erro apareça no sistema.
Neste artigo, explicamos o que são usernames e BSUID, como cada um funciona na prática e o que sua operação precisa fazer antes da mudança.
O que é o username do WhatsApp
O username é um identificador no formato @nome que passa a representar contas no WhatsApp como alternativa ao número de telefone. A adoção é opcional, mas as consequências são diferentes dependendo de quem configura.
Do ponto de vista operacional, a mudança mais relevante está no que chega nos eventos da API: a empresa pode deixar de receber o número de telefone. E quando isso acontece sem preparação, é a experiência do usuário que sofre primeiro.
Para o usuário final
Quando uma pessoa configura um @nome, o número de telefone dela fica oculto para empresas com as quais ainda não teve contato. Do ponto de vista do usuário, a experiência muda pouco: ele só escolhe um @nome e passa a ter mais controle sobre o próprio número. Do ponto de vista de quem opera o WhatsApp, o impacto é outro: o payload do webhook muda, o campo que identifica o contato pode chegar vazio, e qualquer fluxo construído sobre o número precisa ser revisado.
Para empresas e organizações
Empresas também podem adotar usernames. Aqui a lógica é diferente: o número de telefone comercial continua visível no perfil, mesmo com um @nome configurado. O benefício está na descoberta e no alcance.
Com um username, qualquer pessoa pode encontrar e iniciar contato pelo @nome, sem precisar salvar um número. Cada username gera automaticamente um link no formato wa.me/nomedousuario, que pode aparecer em sites, embalagens, anúncios, bios de redes sociais e campanhas offline.
Para organizações que operam em múltiplos países, unidades ou segmentos, vale planejar uma convenção de nomenclatura desde agora. Exemplos: @SuaMarca para o perfil global, @SuaMarca_BR para o Brasil, @SuaMarca_Vendas para o time comercial.
Operações que já usam múltiplos números no mesmo portfólio precisam mapear qual username vai para qual número antes de reivindicar: a associação é feita na API e não pode ser desfeita sem apagar o username.
Regras do username comercial
O username aceita apenas letras (a-z), dígitos (0-9), ponto e sublinhado. Precisa ter entre 3 e 35 caracteres, com ao menos uma letra, e não pode começar ou terminar com ponto.
Maiúsculas e minúsculas são iguais. Mas ponto e sublinhado fazem diferença: “marca.vendas” e “marca_vendas” são usernames distintos. Um padrão claro hoje evita fragmentação depois.
O que é o BSUID
BSUID significa Business-Scoped User ID. É um identificador técnico gerado automaticamente pela Meta, exclusivo por portfólio de negócios. A documentação técnica está na página de desenvolvedores da Meta.
Ele foi criado para resolver um problema direto: quando o usuário adota um username e o número some do payload, as operações precisam de outro jeito de reconhecer esse contato. O BSUID cumpre esse papel de forma estável.
Como o BSUID protege a privacidade
O mesmo usuário tem um BSUID diferente para cada empresa com a qual se relaciona. A Empresa A não consegue saber qual é o BSUID desse usuário na Empresa B. Isso impede rastreamento cruzado entre portfólios e mantém a identificação restrita ao contexto de cada relação.
Como o BSUID chega na prática
O BSUID aparece nos webhooks dentro dos campos fromUserId (em mensagens recebidas) e toUserId (em status/confirmações de envio). No Brasil, o formato começa com o prefixo BR. seguido de uma sequência alfanumérica. O valor completo deve ser armazenado e usado exatamente como recebido.
Dois comportamentos que a operação precisa conhecer: e que afetam diretamente como o histórico do cliente é mantido no CRM:
- Se o usuário trocar o username, o BSUID permanece o mesmo
- Se o usuário trocar o número de telefone, um novo BSUID pode ser gerado e os vínculos precisam ser atualizados
Os três identificadores que passam a coexistir
A partir de 2026, três identificadores estão presentes no WhatsApp ao mesmo tempo: e qualquer sistema de atendimento que use apenas o número de telefone como chave de busca vai começar a falhar silenciosamente quando o terceiro entrar em cena.
- Número de telefone: identifica uma linha física, pode ser ocultado pelo usuário
- Username (@nome): identifica a conta no app, opcional e editável
- BSUID: identifica o usuário na relação com aquela organização específica, estável, não público e exclusivo por portfólio
Eles não se substituem. Dependendo do cenário, um ou mais podem estar presentes ou ausentes nos eventos da API (Application Programming Interface).
O que muda nos webhooks
O campo phoneNumber, que traz o número de telefone, virá como null quando o usuário tem username e não teve interação recente. Os três atributos (phoneNumber, userId e username) sempre são informados na estrutura do evento, mas o valor de cada um pode vir nulo dependendo do cenário:
- Usuário sem username: phoneNumber e userId com valor; username nulo
- Usuário com username e interação recente (ou salvo no Livro de Contatos): phoneNumber, userId e username com valor
- Usuário com username, sem interação recente e fora do Livro de Contatos: userId e username com valor; phoneNumber nulo
Código que assume que phoneNumber chega sempre com valores numéricos vai falhar silenciosamente, sem erro explícito e sem alerta. O sistema precisa verificar o valor de cada campo antes de tentar identificar o contato, e não apenas se ele está presente na estrutura do evento.
Ou seja, isso significa que agora um contato pode chegar sem telefone, apenas com um identificador e o nome de usuário dele. Se o sistema continuar tratando o campo de telefone como se sempre viesse preenchido, ele não vai travar nem mostrar erro na hora, apenas vai aceitar essa ausência como se fosse normal.
O problema só aparece depois, quando alguém tenta usar esse telefone, por exemplo para enviar uma mensagem, e descobre que não há para onde mandar. Por isso é importante checar se cada campo realmente veio preenchido antes de usá-lo.
Os impactos em diferentes áreas
Ressaltando que, na prática, a quebra aparece antes de qualquer alerta. O bot tenta puxar o histórico pelo número, não encontra, e cai no fluxo de novo contato. A fila recebe a conversa sem contexto. O agente pergunta dados que o cliente já forneceu. Isso não é hipótese: é o comportamento padrão de qualquer sistema que não tratou o BSUID. Os impactos por área são:
- Atendimento e suporte: o bot não reconhece o contato e o histórico se perde. O agente começa do zero sem saber com quem está falando
- Vendas e pré-venda: leads que chegam via username podem não ser identificados no CRM, quebrando o funil e perdendo o contexto da jornada
- Cobrança e financeiro: contatos de cobrança que dependem de número de telefone falham quando o número não está disponível no payload
- Marketing e campanhas: usuários com username que chegam via anúncios CTWA (Click to WhatsApp) não recebem a mensagem sem adaptação. Relatórios ficam com lacunas de identificação
- TI (Tecnologia da Informação) e desenvolvimento: o parsing do webhook precisa suportar campos novos sem quebrar. A lógica de busca no CRM precisa de fallback por BSUID
- Analytics e dados: usuários não mapeados corretamente geram métricas inconsistentes e decisões baseadas em dados incompletos
O que fazer e quando
Quem já opera na API oficial com um BSP (Business Solution Provider, parceiro homologado pela Meta) como a Dígitro tem o caminho mais curto: os campos novos já estão disponíveis, o suporte técnico existe e a transição pode ser planejada com antecedência.
A adaptação principal está na forma de armazenar e consultar identificadores. O correto não é substituir o telefone pelo BSUID. É ter um identificador interno próprio, como, por exemplo, o customer_id, e associar a ele tanto o telefone quanto o BSUID. Quando um estiver ausente, o outro resolve.
Ações por prazo
- Agora Verificar se o parsing do webhook suporta campos extras sem quebrar. Os novos campos são aditivos, mas código que não os espera pode falhar. Planejar onde ToUserId e fromUserId vão ser armazenados.
- Maio Começar a capturar o BSUID de cada evento. Adicionar fallback no CRM para buscar por BSUID quando o número não estiver presente. Construir o mapeamento entre telefone e BSUID conforme as interações chegam.
- Antes de agosto: testar envio de mensagens usando userId:{BSUID} no campo to. Validar payload, relatório de entrega e continuidade da conversa. Tratar a ausência do número de telefone em todos os fluxos que dependem desse dado.
O Livro de Contatos como rede de segurança
A Meta lançou em abril de 2026 o Contact Book, que mapeia automaticamente o vínculo entre telefone e BSUID a cada interação. Ele atua no backend da plataforma e ajuda a evitar quebras durante a transição.
Para quem opera bots e automações: o vínculo é registrado automaticamente a cada mensagem trocada, e o número continua chegando no webhook mesmo que o usuário tenha adotado um username depois.
O número de telefone permanece visível nos webhooks quando:
- Houve troca de mensagens com aquele usuário nos últimos 30 dias
- O usuário está salvo no Livro de Contatos da empresa
Uma mensagem entregue com duplo check já conta como interação. Não precisa de resposta.
Campanha de reengajamento antes de agosto
Qualquer mensagem enviada para um número antes de agosto já registra aquele contato no Livro de Contatos. Mesmo que o usuário adote um username depois, o vínculo está salvo e o número continua visível.
Não precisa ser elaborado. O objetivo é garantir que a base ativa passe pelo Livro de Contatos antes que os usernames fiquem disponíveis no Brasil.
O cronograma de 2026
- Maio: BSUIDs passam a aparecer nos webhooks da API oficial. Os campos ToUserId e fromUserId chegam nos eventos.
- Junho: início dos testes de usernames. Organizações podem reivindicar seus @nomes via Meta Business Suite ou API. O status fica como reserved até agosto
- Agosto: usernames disponíveis para usuários brasileiros. A operação precisa estar pronta antes disso
- 2026 em diante: expansão global e crescimento gradual do volume de usuários com username ativo
O ponto central da mudança
O número de telefone era ao mesmo tempo dado de contato e chave de identificação. Agora, essas duas funções se separam. Qualquer bot, fila ou automação construída sem essa distinção vai tratar um cliente conhecido como se fosse desconhecido.
O número continua sendo um dado de contato. Mas para usuários com username, a chave de identificação passa a ser o BSUID. Operações que não reconhecem essa distinção vão perder histórico, travar fluxos e tratar contatos conhecidos como desconhecidos.
A Dígitro já está preparada para essa transição e trabalha junto com cada cliente para garantir continuidade.
Quer ir mais fundo nesse tema?
Preparamos dois materiais completos sobre essa mudança:
- E-book completo: Usernames e BSUID no WhatsApp O guia definitivo da Dígitro para gestores e equipes de atendimento, vendas e comunicação. Cobre os cenários, o cronograma, as exceções e o que adaptar em cada área.
- Guia Rápido: 3 páginas com o essencial Para quem precisa entender o impacto e as ações prioritárias de forma direta e objetiva.
