Mapa da trilha
Conteudo detalhado
๐งฉ BSUID na pratica
Como tirar o BSUID do papel โ modelagem, migracao do wa_id, e o que muda no seu banco de dados.
Tabela contatos_whatsapp com PK composta (business_id, bsuid). Numero vira coluna opcional.
Modelagem certa evita refactor doloroso quando username decolar.
Indice unico em (business_id, bsuid), foreign keys de mensagens, conversas e tickets para essa tabela.
Periodo de transicao mantendo wa_id E bsuid no mesmo registro. BSUID vira fonte de verdade quando o usuario oculta numero.
Migracao big bang quebra producao. Estrategia incremental sobrevive.
Backfill via webhook, leitura preferencial por BSUID, deprecacao do wa_id em prazo definido.
BSUID conecta a conversa WA com o registro do cliente no CRM. Mas voce precisa de ALGUM ato pra vincular (login, codigo, dados).
Sem vinculacao explicita, BSUID e so um ID โ nao identifica QUEM e o cliente.
Account linking via OTP, codigo curto na primeira mensagem, validacao por dados (CPF/email).
Continuar 100% baseado em wa_id leva a clientes "fantasmas" quando o numero some, perda de historico e bugs sutis.
Quem adia, paga em incidentes na producao.
Cliente vira "novo cliente" cada vez que muda visibilidade. Atendimento perde contexto.
Solution Providers (BSPs) โ Twilio, Zenvia, 360dialog, MessageBird, Gupshup โ estao atualizando SDKs para expor BSUID.
Saber se o seu BSP ja entrega o campo evita workarounds desnecessarios.
Cheque release notes. Quem ainda nao expoe, pressione.
Semana 1-2: modelagem. 3-6: backfill e leitura dupla. 7-10: escrita preferencial. 11-12: deprecacao.
Sem cronograma, projeto fica esquecido ate o dia que estoura.
Marcos: schema OK, backfill OK, leitura OK, escrita OK, wa_id deprecated.
๐ Integracao Cloud API
Webhooks, envios, templates โ o que muda no codigo quando voce passa a usar BSUID.
Payload contem messages[], contacts[]. BSUID em contacts[i].user_id (campo equivalente).
Sem saber o campo certo, voce continua salvando so wa_id.
Cheque doc oficial โ campo exato pode evoluir.
A Cloud API aceita BSUID como destinatario quando o usuario ja iniciou conversa (sessao 24h ou template aprovado).
Vai precisar de cliente HTTP que sabe enviar BSUID sem cair no fallback de E.164.
Sessao de 24h continua valendo. Templates fora da sessao continuam exigindo aprovacao.
Templates de mensagem (HSM) sao enviados pra BSUID como destinatario. Variaveis ainda funcionam.
Time de marketing precisa saber que envio em massa nao quebra com username.
Conceito de "marketing categoria" se aplica igual. Opt-in continua sendo legalmente exigido.
Mesmo usuario, mesma empresa = mesmo BSUID. Use isso como chave de dedupe ao receber webhooks repetidos.
Webhooks duplicam por retry. Dedupe por BSUID + message_id evita registros fantasmas.
Chave idempotente = (business_id, bsuid, message_id).
Meta entrega numero de teste e webhook de teste. Use ambos antes de ir pra producao.
Testar com numero real do CEO = receita de incidente.
Sandbox primeiro. Testes E2E com fixtures de BSUID antes do deploy.
Logs estruturados com {business_id, bsuid, message_id, status} permitem rastrear sem precisar de PII.
Quando algo quebra, voce precisa achar rapido sem expor numero em logs.
BSUID e relativamente seguro em logs (pseudonimizado). Numero e PII pura โ evite.
๐ CRM e conformidade
LGPD, retencao, analytics โ como tirar valor do BSUID sem violar legislacao.
BSUID + mensagens = dado pessoal. Trate-o como trataria um email ou telefone.
"Pseudonimizado" nao quer dizer "fora da lei". ANPD entende como dado pessoal.
Base legal, finalidade, retencao โ tudo se aplica.
Registre BSUID no ROPA com finalidade (atendimento, marketing) e base legal (execucao de contrato ou consentimento).
Em fiscalizacao, voce precisa apresentar.
Diferencie marketing (consentimento) de atendimento (execucao de contrato).
Cliente pediu exclusao? Apague TODOS os registros vinculados ao BSUID โ mensagens, ticket, historico, eventos.
Esquecer historico = multa.
Job de exclusao que percorre todas as tabelas que tem (business_id, bsuid).
Defina prazo de retencao por finalidade. Apos prazo, expurgo automatizado.
Guardar pra sempre vira problema legal e custo de storage.
Atendimento ativo: 5 anos. Inativo: anonimizar ou expurgar.
Use BSUID como user_id de eventos: TMA, retencao, conversao โ sem precisar do telefone.
Reduz superficie de PII em dashboards e exports.
Junte com CRM SOMENTE quando precisar โ segrega ambientes.
Reserve @suamarca o quanto antes. Substitua "Fale conosco: +55..." por "Fale conosco: @suamarca" em todo o material.
Quem chega primeiro pega o nome. Squatting vai acontecer.
Politica de disputa da Meta deve seguir o modelo Instagram (trademark, etc.).