BSUID e Usernames no WhatsApp: A Maior Mudança da API da Meta em Anos

Há uma mudança silenciosa acontecendo nas entranhas da API do WhatsApp. Ela não aparece no changelog como uma breaking change. Ela não vai derrubar sua integração da noite para o dia. Mas ela vai, gradualmente ao longo de 2026, tornar obsoleta a suposição que toda plataforma de atendimento, todo CRM e todo bot construído nos últimos anos carrega como verdade fundamental: o cliente é seu número de telefone.

Essa mudança tem nome: BSUID Business-Scoped User ID. E ela vem acompanhada de um recurso que o WhatsApp nunca teve e que o torna, finalmente, mais parecido com Instagram e Telegram: usernames.

O que são os Usernames do WhatsApp?

Em junho de 2026, a Meta começa a liberar para usuários em países selecionados incluindo o Brasil a possibilidade de criar um nome de usuário único no WhatsApp. Pense em algo como @joaosilva ou @mariaoliveira. A diferença do número de telefone é radical: o username é escolhido pelo usuário, é público por padrão, e permite que alguém inicie uma conversa com uma empresa sem nunca revelar seu número.

Isso não é uma mudança cosmética. Para o ecossistema de atendimento ao cliente — e especialmente para quem opera uma plataforma de atendimento no WhatsApp — representa uma inversão no fluxo de informação. Hoje, quando um cliente manda mensagem para o seu WhatsApp Business, você recebe automaticamente o número de telefone dele. Com os usernames, se esse cliente adotou um @handle, você pode receber apenas o identificador novo sem o +55 11 9xxxx-xxxx.

O modelo se aproxima do e-mail em alguns aspectos: você pode conhecer o endereço da pessoa sem conhecer o número do celular. Mas tem uma diferença importante que veremos a seguir: esse identificador não é portátil entre empresas.

Ilustração de dispositivo móvel e comunicação

O Que é o BSUID?

O BSUID (Business-Scoped User ID) é o identificador que a Meta cria automaticamente para cada par único de usuário + portfólio de negócios. Em outras palavras: para cada cliente seu no WhatsApp, existe um BSUID gerado especificamente para a sua empresa.

O formato é padronizado: prefixo de dois caracteres com o código ISO do país, um ponto, e uma sequência alfanumérica de até 128 caracteres. Por exemplo: BR.13491208655302741918. Simples na aparência, mas com implicações profundas na arquitetura de dados.

A propriedade mais importante do BSUID é justamente a que o torna "scoped": o mesmo usuário tem BSUIDs diferentes para cada empresa. O João Silva que conversa com a sua empresa e com um concorrente tem um BSUID com você e outro completamente diferente com o concorrente. Isso é intencional e protege a privacidade do usuário nenhuma empresa consegue rastrear o comportamento do cliente em outras empresas a partir desse identificador.

A partir de 31 de março de 2026, o BSUID já começa a aparecer nos webhooks da API independentemente de o usuário ter adotado um username ou não. Isso é importante: todo cliente seu já tem um BSUID sendo gerado, você só precisa começar a capturá-lo.

Por Que Isso É uma Mudança Estrutural?

Para entender a magnitude, pense em como a maioria dos sistemas de CRM e atendimento foi construída. O campo wa_id o identificador do WhatsApp sempre foi o número de telefone. Era simples, conveniente e universal: o mesmo número que você guardava no cadastro do cliente era o mesmo que chegava no webhook.

Essa convenção durou mais de uma década. Todo schema de banco de dados, toda lógica de deduplicação, toda automação de marketing, todo bot, toda integração com ERP foi construída com essa premissa. O telefone era simultaneamente o canal de contato, o identificador de sistema e o dado de CRM.

O BSUID quebra essa equivalência. A partir de agora, o identificador de sistema (user_id no webhook) pode existir sem o número de telefone. E quanto mais usuários adotarem usernames, maior será a proporção de conversas onde o wa_id (telefone) estará ausente ou omitido.

Não é exagero dizer que isso exige uma revisão arquitetural em toda plataforma de atendimento que não se preparar. A boa notícia é que a transição é gradual. A má notícia é que os sistemas que não se adaptarem não vão explodir vão silenciosamente perder conversas.

O Risco Real: Silêncio Operacional

Um termo circula entre os especialistas em API da Meta para descrever o que acontece com sistemas não preparados: "Operational Silence" silêncio operacional. O sistema parece funcionar. O dashboard não mostra erros. Mas parte das conversas simplesmente não chegam.

Isso acontece em dois fluxos específicos. Primeiro, nos anúncios Click-to-WhatsApp: quando um usuário com username clica no anúncio e inicia uma conversa, o sistema espera um wa_id que é número de telefone, não encontra, e ou gera um registro duplicado ou descarta a interação. Segundo, nas mensagens de serviço inbound: usuários com username que escrevem para o seu número não são reconhecidos pela deduplicação e podem terminar como clientes "novos" no sistema, perdendo todo o histórico.

O pior cenário não é o sistema quebrando você veria o erro, consertaria. O pior cenário é o sistema aceitando a mensagem, criando um registro duplicado, e o agente atendendo o "novo cliente" sem saber que se trata de alguém com 5 anos de histórico de compras.

O Contact Book: A Proteção que a Meta Oferece

Para mitigar a ruptura, a Meta introduziu em abril de 2026 uma funcionalidade chamada Contact Book um livro de contatos no nível da WABA que armazena automaticamente os pares número de telefone ↔ BSUID de todas as interações anteriores.

O Contact Book funciona assim: sempre que um cliente que já conversou com a sua empresa adotar um username, a Meta mantém a associação entre o BSUID dele e o número de telefone que você já conhece. Por 30 dias após uma interação, o número do cliente continua aparecendo nos webhooks mesmo que ele tenha adotado username.

Isso significa que sua base de clientes já existente está protegida na transição pelo menos por um período. O problema surge com os clientes novos que adotarem username antes de nunca ter entrado em contato com sua empresa. Para eles, você receberá apenas o BSUID, sem telefone.

A boa notícia é que o Contact Book é habilitado por padrão. Você não precisa fazer nada para ativá-lo. Mas precisa começar a capturar o BSUID agora para que a associação exista quando os usernames começarem a ser adotados em massa.

A Timeline Completa da Mudança

A Meta planejou o rollout em fases bem definidas. Entender cada etapa é essencial para priorizar as ações da sua equipe técnica:

O ponto crítico que muitas empresas erram é achar que a mudança só importa em junho. Na verdade, a janela de ouro é agora: do início de abril até junho, você pode capturar BSUIDs de toda a sua base de clientes ativos através do Contact Book, sem esperar que eles adotem usernames. Quem fizer isso terá a transição mais suave possível.

Como o Webhook Muda na Prática

Para quem trabalha com a API diretamente, a mudança no payload do webhook é concreta. Veja como fica a estrutura da mensagem inbound:

{
  "contacts": [
    {
      "profile": {
        "name": "João Silva"
      },
      "wa_id": "5511999991234",
      "user_id": "BR.13491208655302741918",
      "username": "joaosilva"
    }
  ],
  "messages": [
    {
      "from": "BR.13491208655302741918",
      "id": "wamid.xxx",
      "timestamp": "1748822400",
      "text": { "body": "Olá, preciso de ajuda" },
      "type": "text"
    }
  ]
}

Note que há três campos agora no objeto de contato: wa_id (que pode estar ausente para usuários com username), user_id (o BSUID, sempre presente a partir de março/2026) e username (o handle, se o usuário tiver adotado). O campo from nas mensagens também passa a aceitar o BSUID diretamente.

Qualquer sistema que faça const customerId = message.from e assuma que o resultado é sempre um número de telefone precisa ser revisado. O campo from pode ser um BSUID.

O Que Fazer com Mensagens Sem Número de Telefone

Uma das perguntas mais frequentes é: e quando o cliente é identificado apenas pelo BSUID, sem telefone? A resposta depende do seu caso de uso.

Para atendimento ao cliente padrão, o BSUID é suficiente. Você consegue responder à conversa, registrar o histórico, ativar automações e até identificar o cliente se já estiver no seu CRM vinculado ao BSUID. A ausência do telefone não impede o atendimento.

Para casos onde o telefone é necessário autenticação por OTP, envio de SMS de confirmação, integração com sistemas legados que só aceitam telefone a Meta criou um fluxo nativo de coleta. O WhatsApp oferece um botão de CTA que o usuário clica para autorizar o compartilhamento do número com a empresa. Isso é consent-based: o usuário escolhe compartilhar ou não.

{
  "type": "interactive",
  "interactive": {
    "type": "cta_url",
    "body": {
      "text": "Para continuar, precisamos do seu número de telefone."
    },
    "action": {
      "name": "phone_number_share",
      "parameters": {}
    }
  }
}

Importante: mensagens de autenticação (OTP) só funcionam com número de telefone. O BSUID não substitui o telefone para esse tipo de comunicação. Se o seu bot de onboarding depende de verificação por SMS, esse fluxo precisa ser revisado para solicitar o número antes de enviar o OTP.

Impacto no CRM: Da Dimensão Única ao Modelo Híbrido

A mudança mais profunda não é técnica é de modelo de dados. Hoje, a maioria dos CRMs usa o telefone como chave primária ou como único identificador do WhatsApp. Esse modelo precisa evoluir para o que especialistas chamam de identidade bidimensional: telefone E BSUID como campos independentes, ambos podendo servir como chave de busca.

A migração do schema envolve pelo menos quatro passos. Para quem usa um AI CRM, esse ajuste tem implicações diretas na integração de IA com CRM, especialmente na lógica de atualização automática de registros. Primeiro, adicionar o campo bsuid na tabela de contatos ou clientes. Segundo, garantir que o campo aceite nulo (para clientes que nunca interagiram pelo WhatsApp após março/2026). Terceiro, criar índice de busca no campo BSUID as queries de lookup vão precisar ser rápidas. Quarto, implementar lógica de merge: quando chegar uma mensagem com BSUID e telefone, cruzar com registros existentes para evitar duplicatas.

ALTER TABLE contacts ADD COLUMN whatsapp_bsuid VARCHAR(135) UNIQUE;
CREATE INDEX idx_contacts_bsuid ON contacts (whatsapp_bsuid);

O risco de não fazer isso é a proliferação de registros duplicados. O mesmo cliente entra pelo telefone em fevereiro e pelo username em agosto, e você tem dois perfis no CRM, dois históricos separados, e o agente que atende em agosto não sabe que o cliente já foi tratado seis meses antes.

A Lógica de Deduplicação Correta

A lógica de identificação de cliente precisa ser reimplementada com uma estratégia de fallback. A hierarquia recomendada é:

1. Buscar pelo BSUID → campo user_id do webhook
2. Se não encontrar, buscar pelo telefone → campo wa_id
3. Se não encontrar em nenhum, criar novo registro com o BSUID
4. Se encontrar pelo telefone mas não tiver BSUID, atualizar o registro com o BSUID

Esse fluxo garante que clientes existentes sejam corretamente identificados independente de terem adotado username ou não, e que o BSUID vá sendo preenchido progressivamente na sua base.

async function resolveContact(webhook: WhatsAppWebhook): Promise<Contact> {
  const bsuid = webhook.contacts[0]?.user_id;
  const phone = webhook.contacts[0]?.wa_id;
 
  // Tentativa 1: BSUID
  if (bsuid) {
    const byBsuid = await db.contacts.findByBsuid(bsuid);
    if (byBsuid) return byBsuid;
  }
 
  // Tentativa 2: telefone
  if (phone) {
    const byPhone = await db.contacts.findByPhone(phone);
    if (byPhone) {
      if (bsuid && !byPhone.bsuid) {
        await db.contacts.update(byPhone.id, { bsuid });
      }
      return byPhone;
    }
  }
 
  // Novo contato
  return db.contacts.create({ phone, bsuid });
}

BSUID e Privacidade: O Que Isso Significa para o Usuário

Do ponto de vista do usuário, o BSUID é uma proteção de privacidade elegante. Ao adotar um username, o usuário pode interagir com dezenas de empresas sem nunca revelar o número de telefone um dado que hoje serve para spam de SMS, rastreamento de identidade entre plataformas e, em casos extremos, assédio.

A propriedade "business-scoped" do identificador vai além: mesmo que você, empresa A, e a empresa B, concorrente, compartilhassem todos os BSUIDs dos seus clientes, seria impossível cruzar quais usuários são os mesmos. O João Silva tem BR.aaaa1111 com você e BR.bbbb2222 com o concorrente são strings completamente diferentes.

Isso é um posicionamento claro da Meta em resposta às críticas sobre privacidade que a plataforma vem recebendo nos últimos anos. O WhatsApp, com seus 3 bilhões de usuários globais, é uma plataforma privilegiada demais para deixar que o telefone sirva como vetor universal de rastreamento.

Para as empresas, isso significa que a era de tratar o telefone como o "CPF do WhatsApp" acabou. O dado de identidade passa a ser o BSUID válido apenas dentro do seu portfólio, não exportável, e renovado se o usuário mudar de número.

Portabilidade de WABA: Um Detalhe Crítico

Existe um detalhe que a maioria dos guias sobre BSUID não menciona, e que pode gerar dores de cabeça severas para empresas que trocam de BSP (Business Solution Provider): ao migrar sua WABA para outro provedor, a Meta gera novos BSUIDs para todos os clientes.

Isso significa que se você está armazenando BSUIDs no CRM e decide trocar de plataforma de atendimento, todos os BSUIDs salvos tornam-se inválidos após a migração. A associação precisa ser refeita, e o Contact Book começa do zero.

A implicação prática é simples: escolha bem sua plataforma de atendimento antes de começar a armazenar BSUIDs em produção. Uma migração de WABA depois que a base de clientes está identificada por BSUID é significativamente mais complexa do que uma migração hoje.

O Que Muda nos Anúncios Click-to-WhatsApp

Os anúncios Click-to-WhatsApp (CTWA) são um dos fluxos mais impactados pela mudança. Hoje, quando alguém clica num anúncio e inicia uma conversa, o sistema recebe o telefone e pode imediatamente identificar o lead, cruzar com o CRM e acionar automações de qualificação.

Com usernames, um usuário que tem @handle e clica no anúncio vai iniciar a conversa sem revelar o telefone. O from no webhook será um BSUID desconhecido para o CRM. O sistema precisa criar um novo perfil baseado apenas no BSUID e, se precisar do telefone para qualificação ou follow-up por outros canais, solicitar explicitamente.

Para campanhas de performance que medem CAC (Custo de Aquisição de Cliente) e fazem atribuição, isso complica o tracking. Se você hoje usa o telefone para cruzar o lead do WhatsApp com o registro no CRM de vendas, esse fluxo precisa ser adaptado para aceitar o BSUID como identificador primário de atribuição.

Chatbots e Automações: O Que Precisa Mudar

Para operações que dependem de chatbots seja para qualificação de leads, autoatendimento ou triagem a mudança principal é: não assuma que o telefone estará disponível desde o início da conversa.

Bots que fazem const cpf_check = await buscarCadastro(message.from) e assumem que message.from é um telefone precisam ser revisados. A partir de junho, message.from pode ser um BSUID. O lookup precisa contemplar os dois cenários.

Além disso, se o bot pede CPF ou e-mail para identificação e usa o telefone como confirmação secundária, o fluxo precisa ser adaptado. O telefone deixa de ser uma informação que o sistema tem automaticamente passa a ser uma informação que precisa ser solicitada quando necessária.

A boa notícia é que para a maioria dos fluxos de atendimento abertura de chamados, consulta de pedidos, FAQ automatizado o telefone nunca foi realmente necessário. O que era necessário era o identificador único do cliente, que agora pode ser o BSUID.

Como Solicitar o Número de Telefone Quando Necessário

Quando o negócio realmente precisa do telefone para OTP, para integração com sistemas legados, para confirmação de entrega a abordagem correta é solicitar explicitamente usando o fluxo nativo do WhatsApp.

A mensagem deve ser clara e contextualizada, explicando por que o número é necessário. A Meta exige que o pedido seja justificado e o usuário tenha controle sobre compartilhar ou não. Abordagens coercitivas ou que bloqueiam o atendimento caso o número não seja fornecido são contra a política da plataforma e podem resultar em suspensão da WABA.

A melhor prática é tornar o telefone opcional sempre que possível e criar um caminho alternativo de atendimento para quem não quiser compartilhar. Em muitos casos, o BSUID é suficiente para oferecer uma experiência completa de atendimento e forçar a coleta do telefone vai na contramão da tendência de privacidade que a Meta está estabelecendo.

O que Muda para Quem Usa Plataformas de Atendimento

Se você usa uma plataforma de atendimento (helpdesk, chatbot as a service, etc.) em vez de integrar diretamente com a API, a responsabilidade técnica de adaptar webhooks e schema de dados é da plataforma não da sua empresa.

Mas isso não significa que você pode simplesmente esperar. O que você precisa verificar é: a plataforma que uso está adaptando para BSUID na timeline correta? A checklist mínima:

• O campo BSUID já está sendo capturado nos webhooks desde 31 de março?
• O CRM da plataforma já tem campo para BSUID no perfil do contato?
• A deduplicação já contempla lookup por BSUID?
• Há comunicação clara sobre quando isso estará disponível?

Plataformas que não responderem essas perguntas de forma satisfatória até maio de 2026 representam um risco operacional real para o segundo semestre.

Usernames para Empresas: Como Reivindicar o Seu

Não são apenas os usuários que podem ter usernames as empresas também. A Meta está liberando para negócios a possibilidade de reivindicar um handle baseado no nome de exibição cadastrado na WABA, na conta verificada do Meta Business, ou nos handles do Facebook e Instagram.

Ter um username empresarial tem benefícios diretos: clientes conseguem encontrar seu negócio pelo handle, sem precisar salvar o número. O link wa.me/c/seuhandle funciona em anúncios, bios de Instagram, assinaturas de e-mail e QR codes. É uma melhora significativa em descoberta e conversão.

A janela para reivindicação começa em junho de 2026. Empresas com conta WABA verificada têm prioridade. Recomenda-se fortemente garantir que o nome de exibição da WABA esteja correto e atualizado antes dessa data o username será derivado dele.

Análise de Impacto por Tipo de Operação

O impacto do BSUID varia significativamente dependendo do perfil da operação:

Atendimento ao cliente (CS) Impacto médio. O histórico de clientes existentes está protegido pelo Contact Book. O maior risco é na abertura de chamados por novos clientes sem telefone. Adaptação na deduplicação resolve.

Vendas e SDR via WhatsApp Impacto alto. Qualificação de leads depende frequentemente de cruzar o contato do WhatsApp com o CRM de vendas. Com BSUID como identificador, a jornada do lead precisa ser reimaginada — o artigo sobre qualificação de leads B2B com IA mostra como essa jornada pode ser redesenhada de forma conversacional.

Marketing e campanhas Impacto alto. Listas de transmissão existentes (outbound para números conhecidos) não mudam. Mas novos leads captados via CTWA podem chegar sem telefone, impactando segmentação e automações de nutrição.

Suporte técnico e CX Impacto baixo a médio. Desde que a plataforma de atendimento se adapte corretamente, o agente não sente diferença no atendimento. O histórico unificado é o maior benefício um cliente que muda de número mas mantém o username continua reconhecível pelo BSUID.

O Novo Paradigma de Identidade no WhatsApp

É útil dar um passo atrás e entender o movimento maior que o BSUID representa. A Meta está construindo uma infraestrutura de identidade que funciona sem depender do número de telefone. Isso não é apenas privacidade é preparação para um futuro onde o WhatsApp seja usado em dispositivos sem chip, em contas corporativas desvinculadas de números pessoais, e potencialmente em outros contextos onde o telefone não é o vetor natural.

O BSUID é a primeira peça desse quebra-cabeça. Ele garante que mesmo sem o telefone, a identidade do usuário seja estável, verificável e única dentro de um relacionamento com uma empresa. O next step lógico é imaginar autenticação por passkey, login sem número, e contas WhatsApp atreladas a identidades digitais mais ricas.

Para o mercado brasileiro de atendimento ao cliente que é, via WhatsApp, um dos mais sofisticados do mundo isso representa uma oportunidade. Empresas que construírem uma arquitetura de dados e uma estratégia de atendimento preparada para o BSUID hoje estarão anos à frente das que esperarem a mudança chegar para reagir.

O Plano de Ação em 5 Etapas

Independente do seu stack tecnológico, esse é o roteiro recomendado para se preparar:

Etapa 1 Diagnóstico (agora)
Mapeie todos os sistemas que recebem ou enviam dados pelo WhatsApp. Liste todos os pontos onde o telefone é assumido como obrigatório: campos de banco de dados, validações de formulário, lógica de deduplicação, queries de CRM, APIs internas.

Etapa 2 Atualização do schema (abril/maio)
Adicione o campo BSUID em todos os sistemas relevantes. Torne o telefone opcional onde for possível. Implemente a lógica de lookup bidimensional (BSUID + telefone).

Etapa 3 Coleta e enriquecimento (a partir de abril)
Comece a capturar BSUIDs dos webhooks desde já. O Contact Book da Meta já estará mapeando pares telefone ↔ BSUID use esse período para enriquecer sua base de clientes existente.

Etapa 4 Teste (maio/junho)
Use a janela de testes da Meta em maio para enviar mensagens usando BSUID. Valide o end-to-end: nova conversa chega só com BSUID → deduplicação funciona → histórico correto → resposta é entregue.

Etapa 5 Monitoramento pós-lançamento (jun em diante)
Acompanhe as métricas de duplicidade de contatos, conversas perdidas e taxa de resolução. Problemas nessas métricas após junho podem indicar que a adaptação ao BSUID não foi completa.

O Que a Tolky Está Fazendo

A Tolky acompanha de perto as mudanças na API da Meta e está adaptando toda a infraestrutura de identificação de contatos para suportar o BSUID nativo. Isso inclui schema de dados, deduplicação inteligente e integração com o Contact Book da Meta.

Para nossos clientes, a transição será transparente: o histórico de atendimento continuará unificado, os BSUIDs serão capturados automaticamente, e a plataforma saberá buscar o contato correto independente de a mensagem chegar com telefone ou com BSUID. Nenhuma ação técnica será necessária por parte da sua equipe.

Se você usa uma plataforma diferente, agora é o momento certo de perguntar ao seu provedor qual é o plano deles para o BSUID. A resposta que você receber vai dizer muito sobre a maturidade técnica da solução que você está usando.

A mudança do BSUID não é o fim do número de telefone no WhatsApp. A grande maioria dos seus clientes ainda vai interagir com telefone visível por bastante tempo. Mas é o início de uma nova era na qual a identidade do usuário pertence ao usuário não ao canal e as plataformas de atendimento precisarão ser mais sofisticadas para acompanhar.

Quem se preparar agora passa por essa transição sem turbulência. Quem esperar vai descobrir o problema pelos sintomas: duplicatas no CRM, histórico perdido, automações que "simplesmente pararam de funcionar" para uma fatia crescente dos contatos.

A escolha, como sempre, é sobre quando você quer ser surpreendido: agora, quando ainda há tempo de agir com calma, ou depois, quando o problema já está em produção.