WhatsApp Usernames em Junho: BSUID Vai Quebrar Seus Bots

Em junho, qualquer usuário do WhatsApp pode criar um username e esconder o número de telefone de todos os negócios com quem conversa. O campo wa_id com o +5511999999999 que identifica clientes no seu sistema pode deixar de chegar. No lugar vem um BSUID: uma string opaca, única para o seu WABA, intransferível. Se o agente ou CRM usa o número como chave primária de contato, ele vai reconhecer o mesmo usuário como desconhecido toda vez que o número estiver oculto.

A mudança já começou. A Meta incluiu o campo bsuid nos payloads de webhook em abril de 2026. O suporte a envio de mensagens por BSUID entrou em rollout em maio. Usernames para usuários finais chegam em junho. Você tem semanas para atualizar o código, ou vai descobrir o problema em produção.

O Que É BSUID e Por Que Ele Já Está No Seu Webhook?

Business-Scoped User ID (BSUID) é o novo identificador primário de usuário na WhatsApp Business Platform. A Meta criou o campo para suportar usernames: quando um usuário ativa o username e oculta o número, o BSUID substitui o wa_id numérico nos fluxos da API.

Três características definem como BSUID funciona na prática:

• Único por negócio: o mesmo usuário tem BSUIDs diferentes para cada empresa. Não é possível cruzar dados entre dois WABAs distintos, mesmo sendo da mesma empresa com números diferentes.
• Mais estável que o telefone: o BSUID não muda se o usuário troca de chip ou número. Para histórico de longo prazo, é mais confiável como chave primária do que o telefone.
• Já em produção: o campo bsuid aparece nos payloads de webhook desde abril de 2026. Você provavelmente já está recebendo ele sem processar.

Timeline confirmada pela Meta: BSUIDs nos webhooks desde abril 2026. Envio de mensagens por BSUID: maio 2026 (rollout em andamento). Usernames para usuários finais: junho 2026 em países de teste, expansão gradual.

O Ângulo Que Ninguém Está Comentando

A narrativa que circula sobre usernames do WhatsApp é a de privacidade do usuário. A questão real para devs é diferente: a Meta está trocando o campo de identidade primário da API depois de mais de uma década usando número de telefone. Isso não é só uma feature de privacidade.

Por um lado, BSUID é objetivamente melhor como identificador de longo prazo. Usuários que trocam de número (e no Brasil isso é frequente com portabilidade) sempre quebravam o histórico em CRMs baseados em WhatsApp. Com BSUID, a identidade persiste independente do número.

Por outro lado, qualquer sistema construído assumindo que wa_id == telefone vai falhar de forma silenciosa. Não vai lançar exceção. Vai criar um contato novo para alguém que já existe, perder contexto acumulado e exibir histórico errado no atendimento. O tipo de bug que você descobre no suporte, não no log.

O Que Vai Quebrar Quando Usuários Ativarem o Username?

A resposta direta: qualquer código que assume que o identificador do usuário é sempre um número de telefone. Essa premissa foi universal desde que a WhatsApp Business API existe. A partir de junho ela deixa de ser verdade para usuários com username ativo.

Os pontos de falha mais frequentes em bots e automações:

• CRM indexado por telefone: usuário que ativou username aparece como contato novo, histórico de conversas anterior fica órfão.
• Deduplicação por wa_id: cria registros duplicados quando o mesmo usuário aparece com número visível em um momento e oculto em outro.
• Lookups de enriquecimento por telefone: SELECT * FROM clientes WHERE phone = ? retorna vazio para usuários com número oculto.
• Memória e contexto em agentes: frameworks que armazenam threads por número de telefone perdem o contexto acumulado quando o campo muda.
• Analytics de funil: a jornada do cliente aparece fragmentada, com gaps toda vez que o usuário muda de estado entre número visível e username.

O Chatwoot abriu a issue #13837 em março de 2026 especificamente para suporte a BSUID. A Twilio documentou a mudança no changelog com alerta de urgência para parceiros. Se plataformas enterprise com times dedicados ainda estão atualizando em maio, a quantidade de automações artesanais que vão quebrar silenciosamente em junho é expressiva.

Como Atualizar o Código Antes de Junho?

A migração tem dois momentos: captura no webhook e envio via API. Para os dois, a lógica é a mesma: BSUID tem prioridade quando presente, número de telefone é o fallback para usuários sem username ativo.

Handler de webhook atualizado em Node.js:

// Antes: identificador era sempre o número
function getUserIdentifier(message) {
  return message.from; // "+5511999999999"
}

// Depois: BSUID tem prioridade quando disponível
function getUserIdentifier(message) {
  return message.bsuid || message.from;
}

// Upsert de contato com lógica de deduplicação
async function upsertContact(message) {
  const bsuid = message.bsuid || null;
  const phone = message.from || null;

  // Tenta localizar por BSUID primeiro
  let contact = bsuid
    ? await db.contacts.findOne({ where: { bsuid } })
    : null;

  // Fallback: busca por telefone
  if (!contact && phone) {
    contact = await db.contacts.findOne({ where: { phone } });
  }

  if (contact) {
    // Vincula BSUID ao contato existente se ainda não tinha
    if (bsuid && !contact.bsuid) {
      await contact.update({ bsuid });
    }
  } else {
    // Cria contato novo com os dados disponíveis
    await db.contacts.create({ bsuid, phone });
  }

  return contact;
}

No banco, adicione bsuid VARCHAR(255) NULL UNIQUE na tabela de contatos. A constraint UNIQUE previne duplicatas durante o período de transição quando usuários alternam entre número visível e username. Para envio de mensagens, o campo to na API aceita BSUID ou número a partir de maio 2026.

A Remoção dos Tiers de 100K: A Outra Mudança do Mesmo Período

Junto com BSUID, a Meta removeu os tiers intermediários de mensagens em Q2 2026. Antes, escalar de 250/dia para 100K levava meses de operação com qualidade comprovada. Agora, business verificado começa direto com 100K mensagens/dia.

Aspecto	Até Q1 2026	A partir de Q2 2026
Limite inicial	250 mensagens/dia	100K mensagens/dia
Caminho para produção real	Meses de tier progression manual	Semanas (tempo de Business Verification)
Controle anti-spam	Bloqueio por tier	Portfolio Pacing em tempo real
Risco operacional	Lento para escalar, seguro	Um lote ruim pausa toda a fila

O Portfolio Pacing merece atenção: campanhas são enviadas em lotes e a Meta monitora engajamento em tempo real. Se a taxa de bloqueios ou spam reports subir, o restante da campanha é pausado automaticamente. Qualidade de mensagem se torna mais crítica do que antes porque o controle deixa de ser por volume e passa a ser por reputação acumulada.

Como a Verboo Lida Com BSUID Nativamente

O CRM nativo da Verboo já processa BSUID como identificador primário. Quando um usuário com username ativo envia mensagem para um Assistente, o BSUID é armazenado automaticamente e vinculado ao contato. O histórico de conversa, a memória nativa e o contexto acumulado continuam disponíveis, independente do estado do número.

Para quem usa a API REST da Verboo, o campo bsuid já aparece nos eventos de mensagem recebida. A deduplicação acontece na plataforma sem configuração adicional. Você constrói a lógica de negócio, a camada de identidade já está resolvida.

Para quem mantém infra própria, o checklist mínimo antes de junho:

1. Adicionar coluna bsuid nullable e unique na tabela de contatos
2. Atualizar webhook handler para capturar message.bsuid quando presente
3. Implementar deduplicação: busca por BSUID antes de fallback por telefone
4. Atualizar todos os lookups de cliente para incluir BSUID como chave de busca
5. Testar no sandbox de usernames disponível para parceiros Meta

A Verboo já opera nesse modelo. Conheça a plataforma e veja como identidade de usuário é tratada em produção.