Há anos eu venho criticando a decisão do WhatsApp de amarrar 100% da identidade ao número de telefone. Sempre achei que isso era um resíduo da era pré-criptografia-de-ponta-a-ponta, quando o mensageiro ainda dependia da lista de contatos do celular pra existir. Agora, finalmente, a Meta está mexendo nisso. Segundo o Olhardigital.com.br, o WhatsApp começou a liberar um campo pra salvar contatos usando só o username — sem precisar do número. Isso muda muita coisa, e o impacto vai muito além do que parece à primeira vista.
O que realmente mudou no WhatsApp
A mudança tem duas frentes rodando em paralelo, e muita gente tá confundindo as duas. Vou separar.
1. Campo de username ao criar contato
Antes, salvar alguém no WhatsApp era sinônimo de ter o número de telefone da pessoa. Não tinha como escapar disso. Agora, a Meta adicionou um campo novo na tela “Novo contato” (acessada pelo botão “+” na aba Conversas → Novo contato) onde dá pra registrar o @username junto — ou no lugar — do número tradicional.
Isso apareceu pra alguns usuários da versão mais recente da App Store e também pra quem roda a versão beta. O WABetaInfo, que costuma cravar essas coisas, confirmou a novidade no Android e no iOS.
2. Mensagens automáticas de boas-vindas em grupos (iOS)
Aqui é onde fica interessante pra quem programa. A Meta tá testando uma ferramenta que dispara mensagens automáticas quando alguém entra num grupo. Pensa nisso como um webhook de evento group.member.added — basicamente o mesmo conceito que a gente implementa em bots de Discord ou Slack há anos.
Por que essa mudança importa do ponto de vista técnico
Quando você desacopla identidade de telefone, você ganha três coisas que desenvolvedores e usuários avançados vão sentir imediatamente:
Privacidade real, não teatro. Hoje, se eu quero restringir quem vê meu status ou minha foto, eu dependo da minha lista de contatos — que, por definição, é uma lista de números de telefone. Isso vaza metadado. Qualquer pessoa com quem você já trocou uma mensagem fica potencialmente exposta. Com username como identificador, dá pra pensar em permissionamento por handle sem expor DDI+DDD+número.
Portabilidade entre dispositivos. Trocar de número hoje é um parto. Quem já passou por isso sabe: você perde grupos, perde histórico (se não tiver backup), vira fantasma. Um username estável resolve parte desse problema.
Onboarding sem fricção. Quem tá desenvolvendo produto sabe: cada campo a mais na tela de cadastro derruba conversão. Hoje, pra alguém te adicionar no WhatsApp, precisa do seu número. Num país onde muita gente troca de chip a cada 6 meses, isso é uma barreira absurda.
Comparação com Telegram, Signal e Discord
A Meta tá atrasada. Telegram já usa @username como identificador público há mais de uma década. Signal adotou em 2021. Discord nunca teve telefone como requisito — handle + tag numérica desde o dia 1.
O que o WhatsApp tem de diferente é a base instalada: 2 bilhões de usuários. Migrar a forma como as pessoas se identificam nessa escala é um problema de engenharia brutal. Quem já tentou migrar schema em produção com 1 milhão de linhas imagina o inferno de fazer isso com 2 bilhões de contas. Eu, na minha experiência, já vi deploy que precisou de feature flag por hash de usuário pra evitar desastre — e era numa base cinco ordens de grandeza menor.
Na Prática — como testar agora mesmo
Pra quem quer ver a novidade hoje:
- Atualize o WhatsApp na App Store (versão estável mais recente).
- Abra a aba Conversas.
- Toque no + no canto superior.
- Selecione Novo contato.
- Veja se apareceu o campo novo pra username. Se não apareceu, você ainda não tá no rollout gradual — pode esperar alguns dias ou instalar a versão beta do TestFlight.
- Adicione alguém usando só o @username (a pessoa precisa ter um username configurado nas configurações de privacidade).
Sobre as mensagens de boas-vindas: no momento, é iOS only e tá em teste A/B. Não tem como forçar manualmente. Você só descobre se tá no grupo teste quando cria ou entra num grupo novo.
Implicações pra devs — e o que observar na API
Aqui é onde eu quero dar um chute qualificado. Se a Meta seguir a tendência (e tudo indica que vai), a próxima grande jogada é abrir isso pra automação. Quando isso acontecer, o modelo de webhook pra evento “novo membro no grupo” provavelmente vai ser parecido com isso:
// Exemplo conceitual de como um webhook de "novo_integrante" pode funcionar
// quando a Meta abrir a API de automação do WhatsApp Business Cloud
app.post('/webhook/whatsapp', (req, res) => {
const { event, group_id, member } = req.body;
if (event === 'group.member.added') {
// Mensagem de boas-vindas baseada no perfil do novo membro
const welcome = buildWelcomeMessage({
username: member.username,
joinedAt: new Date(),
invitedBy: member.invited_by
});
return sendGroupMessage(group_id, welcome);
}
res.sendStatus(200);
});
function buildWelcomeMessage({ username, joinedAt, invitedBy }) {
return `Olá @${username}! Bem-vindo ao grupo. ` +
`Você entrou em ${joinedAt.toISOString()}. ` +
(invitedBy ? `Convidado por @${invitedBy}.` : '');
}
Note uma coisa importante: o handle aqui é o @username, não o número. Isso é uma decisão de design que muda completamente o contrato da API. Se você já integra com WhatsApp Business hoje, prepare-se pra revisar seu schema de contatos — misturar identificador legado (número) com novo (username) é receita pra bug de duplicação.
Erros comuns que devs cometem com identidade baseada em username
1. Tratar username como chave primária imutável.
Não é. Usuário pode trocar, pode deletar, pode estar indisponível. Sempre tenha um fallback — ID interno, telefone quando disponível.
2. Indexar username com collation errada.
Username é case-insensitive na maioria dos sistemas. Se você indexar com collation binária, vai ter “Yuri” e “yuri” como usuários diferentes. Use NOCASE no SQLite, utf8mb4_unicode_ci no MySQL, ou lower + normalização no Postgres.
3. Esquecer do rate limit.
Resolver username → conta é uma chamada cara. Cache agressivo com TTL curto (5–15 min) é obrigatório em produção. Eu já vi sistema travar porque o lookup de username não tinha cache e virou ponto quente no banco.
4. Misturar canal de identidade com canal de notificação.
O username identifica. O telefone ainda é o canal de envio (por enquanto). Se você mandar mensagem pensando que username == endpoint de envio, vai dar ruim.
5. Não validar no client.
Username normalmente só permite [a-z0-9_], tamanho 3–30. Validar isso no front antes de bater no backend economiza um montão de round-trip e protege contra abuso.
O que isso significa pro ecossistema
Essa mudança é pequena na superfície e enorme no impacto. Quando a Meta desacopla identidade de telefone, ela tá preparando terreno pra três coisas: (1) um modelo de assinatura mais sofisticado (username pago, tipo Telegram Premium), (2) abertura de API pra bots mais robustos, e (3) eventual compatibilidade com federação de identidade entre Meta Messenger, Instagram e WhatsApp.
Quem trabalha com mensageria e atendimento ao cliente deveria começar a revisar agora os schemas de contato, porque essa migração vai acontecer mais rápido do que parece. Cuidado com essa armadilha: quem esperar a Meta anunciar a API oficial pra começar a se adaptar vai chegar atrasado no mercado.
FAQ — Perguntas que um dev faria agora
Quando vai chegar pra todo mundo?
Ninguém sabe ao certo. O padrão da Meta é rollout gradual por país e por hash de usuário. Pode levar de 2 semanas a 3 meses. Quem usa a versão beta do TestFlight geralmente recebe antes.
Posso ter contato salvo só pelo username, sem número?
Sim, é exatamente o que tá sendo testado. O número fica opcional nessa nova modalidade — pelo menos pra quem tá no rollout.
E o número de telefone continua funcionando normalmente?
Sim. Nada quebra. É aditivo — o campo novo se soma ao fluxo existente. Quem ainda prefere adicionar por número não muda nada.
Isso vale pra Android também?
O Olhardigital reporta que o campo de username apareceu em ambas as plataformas, mas a parte de mensagens automáticas de boas-vindas em grupo é iOS only por enquanto.
Tem impacto na criptografia de ponta a ponta?
Não. O Signal Protocol que o WhatsApp usa é independente de como o contato é identificado. Trocar username por número no display não afeta o handshake de chaves — a chave pública continua atrelada à identidade criptográfica da conta, não ao handle visível.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto — especialmente se você já tá testando a versão beta e quer trocar uma ideia sobre o que mudou no schema de contatos do lado client.