Com as atualizações recentes anunciadas pela Meta para o WhatsApp Business API (com prazo final em junho de 2026), teremos uma mudança estrutural: a introdução dos Usernames e do BSUID (Business-Scoped User ID).
Como sabemos, hoje a Blip utiliza o número de telefone como base para gerar o identity do contato no canal WhatsApp. No entanto, com essa mudança, usuários poderão ocultar o número de telefone, e a Meta passará a enviar apenas o BSUID nos webhooks.
Gostaria de entender como a Blip está se preparando para isso, especificamente nos seguintes pontos:
Variável contact.identity: O identificador padrão do usuário na Blip continuará sendo o número de telefone quando disponível? Se o usuário utilizar um username, o identity passará a ser o BSUID (ex: [removed by moderator] )?
Webhooks de Mensagens e Eventos: Como ficarão os retornos de JSON nos Webhooks da plataforma? Teremos um novo campo (ex: external_user_id ou bsuid) dentro do objeto de contato para garantir que nossas integrações de CRM não percam o rastro do cliente?
Ações de "Definir Contato": Atualmente, muitas automações usam o número de telefone como chave. Haverá uma recomendação oficial de migração para que o BSUID seja a chave primária nos bancos de dados externos integrados via Blip?
Histórico e Reidentificação: Se um usuário iniciar uma conversa via Username (BSUID) e, posteriormente, decidir compartilhar o telefone em um fluxo de opt-in, a Blip terá algum mecanismo nativo para fazer o "merge" desses perfis ou atualizar o registro de forma transparente?
Considerando que isso muda a forma como desenhamos nossos fluxos no Builder e como coletamos dados com consentimento, seria ótimo ter uma visão do roadmap técnico da Blip para essa transição.
Acredito que essa é uma dúvida comum para todos que possuem CRMs e automações críticas rodando hoje.
Abraços!
Melhor resposta por Rafael_Figueiredo
Olá, pessoal da comunidade e time Blip!
Com as atualizações recentes anunciadas pela Meta para o WhatsApp Business API (com prazo final em junho de 2026), teremos uma mudança estrutural: a introdução dos Usernames e do BSUID (Business-Scoped User ID).
Como sabemos, hoje a Blip utiliza o número de telefone como base para gerar o identity do contato no canal WhatsApp. No entanto, com essa mudança, usuários poderão ocultar o número de telefone, e a Meta passará a enviar apenas o BSUID nos webhooks.
Gostaria de entender como a Blip está se preparando para isso, especificamente nos seguintes pontos:
Variável contact.identity: O identificador padrão do usuário na Blip continuará sendo o número de telefone quando disponível? Se o usuário utilizar um username, o identity passará a ser o BSUID (ex: [removed by moderator] )?
Webhooks de Mensagens e Eventos: Como ficarão os retornos de JSON nos Webhooks da plataforma? Teremos um novo campo (ex: external_user_id ou bsuid) dentro do objeto de contato para garantir que nossas integrações de CRM não percam o rastro do cliente?
Ações de "Definir Contato": Atualmente, muitas automações usam o número de telefone como chave. Haverá uma recomendação oficial de migração para que o BSUID seja a chave primária nos bancos de dados externos integrados via Blip?
Histórico e Reidentificação: Se um usuário iniciar uma conversa via Username (BSUID) e, posteriormente, decidir compartilhar o telefone em um fluxo de opt-in, a Blip terá algum mecanismo nativo para fazer o "merge" desses perfis ou atualizar o registro de forma transparente?
Considerando que isso muda a forma como desenhamos nossos fluxos no Builder e como coletamos dados com consentimento, seria ótimo ter uma visão do roadmap técnico da Blip para essa transição.
Acredito que essa é uma dúvida comum para todos que possuem CRMs e automações críticas rodando hoje.
Abraços!
@Jeo Araujo tudo bem ?
A Blip está já trabalhando nessa adequação, mas a arquitetura do canal deve permanecer a mesma. Respondendo as duvidas:
1 R : quando tiver o valor de telefone vai vir telefone se não vier vai ser um hash seguindo padrão da meta com sufixo do canal @wa.gw.msging.net 2 R : O retorno passado pelo webhook vai se continuar no padrão de hoje e caso o usuário tenha o id alterado vai seguir o padrão do hash adotado pelo whatsapp. Caso mude para um usuário que vc tinha ele identificado com telefone para o hash você pode peder essa rastreabilidade se ele vier como um novo contato para o bot.
3 R : Haverá um publicação sobre essa alteração e recomendando boas praticas quanto a isso sim. 4 R : Essa parte é delicada, pois tem muitos pontos a serem trabalhados, mas a Blip não quer que percam histórico caso a pessoa resolva compartilhar o telefone, talvez venha apenas como dado dentro da variável do contato para evitar cenário assim, mas nada fechado ainda. Quando tiver tudo pronto será oficializado.
Com as atualizações recentes anunciadas pela Meta para o WhatsApp Business API (com prazo final em junho de 2026), teremos uma mudança estrutural: a introdução dos Usernames e do BSUID (Business-Scoped User ID).
Como sabemos, hoje a Blip utiliza o número de telefone como base para gerar o identity do contato no canal WhatsApp. No entanto, com essa mudança, usuários poderão ocultar o número de telefone, e a Meta passará a enviar apenas o BSUID nos webhooks.
Gostaria de entender como a Blip está se preparando para isso, especificamente nos seguintes pontos:
Variável contact.identity: O identificador padrão do usuário na Blip continuará sendo o número de telefone quando disponível? Se o usuário utilizar um username, o identity passará a ser o BSUID (ex: [removed by moderator] )?
Webhooks de Mensagens e Eventos: Como ficarão os retornos de JSON nos Webhooks da plataforma? Teremos um novo campo (ex: external_user_id ou bsuid) dentro do objeto de contato para garantir que nossas integrações de CRM não percam o rastro do cliente?
Ações de "Definir Contato": Atualmente, muitas automações usam o número de telefone como chave. Haverá uma recomendação oficial de migração para que o BSUID seja a chave primária nos bancos de dados externos integrados via Blip?
Histórico e Reidentificação: Se um usuário iniciar uma conversa via Username (BSUID) e, posteriormente, decidir compartilhar o telefone em um fluxo de opt-in, a Blip terá algum mecanismo nativo para fazer o "merge" desses perfis ou atualizar o registro de forma transparente?
Considerando que isso muda a forma como desenhamos nossos fluxos no Builder e como coletamos dados com consentimento, seria ótimo ter uma visão do roadmap técnico da Blip para essa transição.
Acredito que essa é uma dúvida comum para todos que possuem CRMs e automações críticas rodando hoje.
Abraços!
@Jeo Araujo tudo bem ?
A Blip está já trabalhando nessa adequação, mas a arquitetura do canal deve permanecer a mesma. Respondendo as duvidas:
1 R : quando tiver o valor de telefone vai vir telefone se não vier vai ser um hash seguindo padrão da meta com sufixo do canal @wa.gw.msging.net 2 R : O retorno passado pelo webhook vai se continuar no padrão de hoje e caso o usuário tenha o id alterado vai seguir o padrão do hash adotado pelo whatsapp. Caso mude para um usuário que vc tinha ele identificado com telefone para o hash você pode peder essa rastreabilidade se ele vier como um novo contato para o bot.
3 R : Haverá um publicação sobre essa alteração e recomendando boas praticas quanto a isso sim. 4 R : Essa parte é delicada, pois tem muitos pontos a serem trabalhados, mas a Blip não quer que percam histórico caso a pessoa resolva compartilhar o telefone, talvez venha apenas como dado dentro da variável do contato para evitar cenário assim, mas nada fechado ainda. Quando tiver tudo pronto será oficializado.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
A analisar o ficheiro em busca de vírus
Lamentamos, mas ainda estamos a analisar o conteúdo deste ficheiro, a fim de nos certificarmos de que o mesmo é seguro para descarregar. Agradecemos que tentes de novo dentro de poucos minutos.
