Categoria: Atualizações de produto

Últimas novidades e mudanças de plataforma da WhatsApp Business API e 360Dialog.

  • WhatsApp Flows: como criar formulários e coletar dados dentro do WhatsApp

    WhatsApp Flows: como criar formulários e coletar dados dentro do WhatsApp

    O WhatsApp Flows é um recurso da Cloud API que permite criar formulários de várias telas diretamente dentro de uma conversa do WhatsApp. Os usuários percorrem campos de entrada, menus suspensos e seletores de data sem sair do chat, e o seu sistema recebe os dados coletados como JSON estruturado. A Meta descreve os Flows como uma forma de criar interações estruturadas para mensagens comerciais, em tarefas como geração de leads e recomendação de produtos.[1] Se você desenvolve na WhatsApp Cloud API, os Flows oferecem uma forma nativa de coletar dados estruturados no próprio momento da conversa. Um Flow abre quando o usuário toca em um botão de call-to-action em uma mensagem interativa ou em uma mensagem de template (o tipo de mensagem pré-aprovada que uma empresa pode enviar a qualquer momento), e o formulário em si roda dentro do WhatsApp.

    Principais conclusões

    1. Os Flows exigem a WhatsApp Cloud API e uma conta do WhatsApp Business (WABA). A Meta está dividindo a WABA em duas contas: uma WhatsApp account, que contém o seu número de telefone comercial, e uma Messaging account, que contém os seus templates e o faturamento.
    2. Um Flow sem endpoint de dados (uma URL no seu servidor que o Flow chama para obter dados em tempo real) coleta as respostas do formulário e as envia quando o usuário termina. Um Flow com endpoint troca dados com o seu servidor em tempo real.
    3. Um Flow pode ter até 100 telas, mas a Meta recomenda que cada tarefa leve menos de 5 minutos e que cada tela se concentre em uma única tarefa.
    4. Os Flows que trocam dados com o seu servidor precisam de um par de chaves RSA de 2048 bits, com a chave pública assinada pelo endpoint de criptografia da 360Dialog.
    5. O custo de um Flow é o custo da mensagem que o transporta. A partir de 1º de outubro de 2026, a Meta também cobra pelas respostas enviadas dentro da janela de atendimento ao cliente de 24 horas, o período após a última mensagem do usuário em que você pode responder sem um template.

    Pronto para criar seu primeiro Flow? A 360Dialog oferece acesso à Cloud API, gerenciamento de chaves de criptografia e a infraestrutura para criar e implantar Flows, com preço por número por mês e sem acréscimo sobre as taxas da Meta. Começar a usar a API.

    O que é o WhatsApp Flows e como ele funciona?

    O WhatsApp Flows é um framework de interação estruturada integrado à WhatsApp Business Platform que permite às empresas definir formulários de várias telas com uma definição em JSON, exibir esses formulários de forma nativa dentro do WhatsApp e receber as respostas dos usuários como payloads JSON estruturados via webhook. O usuário nunca sai do chat. Os Flows são compostos por telas (cada tela é um nó em uma máquina de estados), componentes (os elementos de interface de cada tela) e ações (a lógica que avança entre as telas ou envia os dados).

    Um Flow começa quando o usuário toca em um botão de call-to-action anexado a uma mensagem interativa (tipo "flow") ou a uma mensagem de template (tipo de botão FLOW). O botão abre a primeira tela, que contém o layout, os componentes e a lógica de navegação definidos no seu Flow JSON. O usuário preenche os campos e avança pelas telas. Na tela final, a ação complete envia os campos listados no payload dela de volta ao seu sistema, como um payload JSON entregue via webhook.

    A principal diferença em relação a outros métodos de coleta de dados no WhatsApp:

    MétodoEstrutura dos dadosExperiência do usuárioIdeal para
    WhatsApp FlowsPayload JSON estruturadoTelas de formulário tocáveis no chatCaptação de leads, agendamentos, pesquisas, formulários de pedido
    Respostas rápidas em templatesSeleção de um único botãoO usuário toca em uma opção predefinidaConfirmações, opt-ins (consentimento para receber mensagens), roteamento simples
    Coleta por texto livreTexto não estruturadoO usuário digita respostas abertasFeedback aberto, conversas de suporte

    Os Flows resolvem um problema específico: coletar dados estruturados de usuários que já estão em uma conversa do WhatsApp. Se você precisa de um nome, um e-mail, uma data e uma preferência em uma única interação, os Flows permitem coletar os quatro em um só formulário tocável. A coleta por texto livre exige várias rodadas de mensagens e lógica de parsing no seu backend para extrair os mesmos campos.

    Se você precisa de um número da Cloud API para começar a criar Flows, você pode começar a usar a API com a 360Dialog.

    Flows estáticos ou dinâmicos: de qual tipo você precisa?

    A distinção prática é se o seu Flow se conecta a um endpoint de dados. Um Flow sem endpoint de dados define todo o conteúdo no Flow JSON e coleta as entradas do usuário localmente. Um Flow com endpoint de dados envia requisições criptografadas ao seu servidor durante a execução e recebe os dados que preenchem a tela seguinte. Os dois rótulos descrevem abordagens de tratamento de dados que determinam quanta infraestrutura de backend você precisa.

    Sem endpoint de dados: O Flow JSON define cada tela, componente e caminho de navegação na fase de design. As entradas do usuário são coletadas localmente e enviadas como um payload JSON quando o Flow é concluído. Essa abordagem funciona para formulários de captação de leads, pesquisas de feedback e fluxos de cadastro em que todos os campos são conhecidos de antemão. As principais ações são navigate (para avançar entre as telas) e complete (para encerrar o Flow e devolver os dados). O servidor só entra em ação quando o envio final chega via webhook.

    Com endpoint de dados: O Flow envia requisições POST criptografadas ao seu endpoint HTTPS durante a execução, usando a ação data_exchange.[2][4] Seu servidor descriptografa a requisição, processa os dados e retorna o conteúdo da tela seguinte. Isso permite agendamento de consultas com disponibilidade em tempo real, catálogos de produtos com estoque em tempo real ou qualquer cenário em que o conteúdo da tela dependa das seleções anteriores do usuário ou do estado do seu backend. As requisições ao seu endpoint expiram após 10 segundos, e a Meta recomenda uma validade de 2 a 3 dias para o flow_token, para dar tempo aos usuários de interagir.[6]

    As duas abordagens usam a mesma estrutura de Flow JSON e os mesmos componentes. A escolha depende de as suas telas precisarem de dados do seu servidor durante a execução.

    Para conectar os envios de Flows à sua stack de automação atual, veja como funcionam as integrações do WhatsApp com a 360Dialog.

    Quais componentes você pode usar em um Flow?

    Os Flows oferecem mais de 20 tipos de componentes nas categorias de entrada, exibição, navegação e condicionais. Cada tela aceita até 50 componentes e usa um layout de coluna única (SingleColumnLayout, um flexbox vertical).[3] A Meta limita o conteúdo do próprio Flow JSON a 10 MB.

    Principais componentes de entrada:

    • TextInput: Texto de uma linha, e-mail, telefone, número, senha ou código de acesso. Aceita validação por regex (v6.2 ou posterior). Máximo de 80 caracteres por padrão.
    • TextArea: Entrada de texto com várias linhas, 600 caracteres por padrão.
    • Dropdown: Seleção única entre até 200 opções (100 com imagens).
    • RadioButtonsGroup: Seleção única entre até 20 opções. A Meta recomenda um Dropdown quando você tem 8 opções ou mais.
    • CheckboxGroup: Seleção múltipla entre até 20 opções.
    • DatePicker: Seleção de data com formatação independente de fuso horário (v5.0 ou posterior).
    • CalendarPicker: Seleção de uma data ou de um intervalo de datas (v6.1 ou posterior).
    • OptIn: Caixa de seleção de consentimento, até 5 por tela.
    • ChipsSelector: Seletor compacto de múltiplas opções, para 2 a 20 opções (v6.3 ou posterior).

    Os componentes de exibição incluem TextHeading, TextSubheading, TextBody, TextCaption, RichText (v5.1 ou posterior, para textos mais longos formatados em markdown), Image (até 3 por tela) e ImageCarousel (v7.1 ou posterior).

    Os componentes de navegação incluem Footer (obrigatório nas telas terminais, máximo de 35 caracteres), EmbeddedLink (até 2 por tela) e NavigationList (v6.2 ou posterior). Os componentes de upload de mídia (DocumentPicker e PhotoPicker, v4.0 ou posterior) permitem que os usuários anexem arquivos diretamente no Flow.

    Os componentes condicionais (If e Switch, disponíveis a partir da v4.0) permitem mostrar ou ocultar elementos com base nas entradas do usuário ou em valores de dados, e os componentes If podem ser aninhados em até 3 níveis. A ação update_data (v6.0 ou posterior) atualiza a tela em tempo real com base nas interações do usuário, sem ida e volta ao servidor, o que é útil para dropdowns em cascata ou campos calculados.

    Para ver as etapas de configuração na 360Dialog, consulte a nossa documentação de Flows em docs.360dialog.com. A referência completa de componentes está na documentação de componentes da Meta.

    Como criar um Flow pela API? (O caminho com a 360Dialog)

    Criar um Flow pela 360Dialog segue cinco etapas: gerar um par de chaves RSA, fazer o upload da chave pública, escrever o Flow JSON, configurar o endpoint e enviar o Flow aos usuários. As etapas 1, 2 e 4 só são necessárias para Flows que trocam dados com o seu servidor, e a Meta inclui o par de chaves na configuração do endpoint. O WhatsApp Manager também tem um Flows Builder com pré-visualização ao vivo, e o caminho pela API permite gerenciar o Flow JSON a partir dos seus próprios sistemas. Em qualquer um dos caminhos, um Flow pode ter até 100 telas.

    1. Gere seu par de chaves RSA. Crie um par de chaves RSA de 2048 bits com o OpenSSL:
    openssl genrsa -des3 -out private.pem 2048
    openssl rsa -in private.pem -outform PEM -pubout -out public.pem

    Guarde a chave privada em segurança. Você vai usá-la para descriptografar os dados recebidos dos Flows.

    1. Faça o upload da sua chave pública na 360Dialog. Assine e envie a chave pelo endpoint de criptografia da 360Dialog:[5]
    POST https://waba-v2.360dialog.io/whatsapp_business_encryption

    Envie a chave pública completa (incluindo os marcadores BEGIN e END) como business_public_key no corpo da requisição. O endpoint retorna {"success": true} em caso de sucesso. Você pode verificar o status da chave com uma requisição GET para a mesma URL.

    1. Escreva o Flow JSON. Defina suas telas, layouts, componentes e ações de navegação. O JSON exige, no mínimo, um campo version e um array screens. Use a versão do Flow JSON que a Meta recomenda atualmente (7.3): as versões até a 5.0 estão congeladas e não podem mais ser publicadas.[7] Cada tela tem um id, um bloco layout e os campos opcionais data e title. Pelo menos uma tela deve ser marcada como terminal, e toda tela terminal precisa de um Footer. Para Flows com endpoint, defina também data_api_version (a Meta recomenda "4.0"; "3.0" ainda é aceito) e um routing_model que liste quais telas podem vir depois de cada uma.
    1. Configure seu endpoint de dados (somente Flows dinâmicos). Defina o endpoint_uri pela Flows API. Seu endpoint deve aceitar requisições HTTPS POST com um certificado TLS/SSL válido. Todos os payloads são criptografados com RSA de 2048 bits (OAEP-SHA256) na troca de chaves e com AES-128-GCM no payload de dados. Valide as requisições recebidas com o cabeçalho X-Hub-Signature-256 e o app secret do seu aplicativo. Seu endpoint também deve responder aos pings de verificação de integridade (health check): {"action": "ping"} espera {"data": {"status": "active"}}.
    1. Envie o Flow aos usuários. Anexe o Flow a uma mensagem interativa (tipo "flow") ou a uma mensagem de template (tipo de botão FLOW). Uma mensagem interativa de Flow precisa de flow_message_version definido como "3", do texto do botão em flow_cta e de um flow_id ou um flow_name.[8] O changelog da Meta lista o flow_token como opcional; defina um quando precisar associar cada resposta a uma sessão ou a um usuário. Com flow_action definido como "navigate" (o padrão), o flow_action_payload indica a primeira tela e pode preencher campos previamente quando você já conhece os dados do usuário pelo contexto da conversa.

    A 360Dialog, como Official Meta Solution Partner, fornece o endpoint de criptografia e a infraestrutura de API que cuida do gerenciamento de chaves para os Flows. Exemplos de código para a descriptografia no endpoint estão disponíveis em Python, Node.js, PHP, Java, C# e Go na documentação para desenvolvedores da Meta.

    Se a WhatsApp Business API é novidade para você, obtenha a aprovação da sua WhatsApp account antes de criar Flows.

    Três exemplos práticos com Flow JSON

    Os exemplos a seguir mostram a estrutura JSON de três casos de uso comuns. Todos usam a versão 7.3 do Flow JSON, a versão que a Meta recomenda atualmente. A referência completa de componentes e ações está na documentação de Flow JSON da Meta.

    Formulário de captação de leads (uma tela, sem endpoint)

    Um formulário mínimo de captação de leads, com um campo de nome, um seletor de interesse e uma caixa de seleção de consentimento:

    {
      "version": "7.3",
      "screens": [{
        "id": "LEAD_FORM",
        "title": "Entre em contato",
        "terminal": true,
        "layout": {
          "type": "SingleColumnLayout",
          "children": [
            {"type": "TextInput", "name": "full_name",
             "label": "Nome completo", "required": true,
             "input-type": "text"},
            {"type": "RadioButtonsGroup", "name": "interest",
             "label": "Área de interesse", "required": true,
             "data-source": [
               {"id": "sales", "title": "Vendas"},
               {"id": "support", "title": "Suporte"},
               {"id": "partnership", "title": "Parceria"}
            ]},
            {"type": "OptIn", "name": "consent",
             "label": "Aceito receber novidades"},
            {"type": "Footer", "label": "Enviar",
             "on-click-action": {
               "name": "complete",
               "payload": {
                 "full_name": "${form.full_name}",
                 "interest": "${form.interest}",
                 "consent": "${form.consent}"
               }
            }}
          ]
        }
      }]
    }

    A ação complete no Footer encerra o Flow e envia ao seu webhook os campos listados no payload dela, então liste todos os campos de que você precisa. O webhook entrega uma mensagem com tipo "interactive" e tipo interativo "nfm_reply", cujo campo response_json é uma string JSON que contém o flow_token e os valores desses campos.

    Formulário de feedback (duas telas, sem endpoint)

    Um formulário de feedback em duas telas coleta uma avaliação na primeira tela e comentários opcionais na segunda:

    {
      "version": "7.3",
      "screens": [
        {
          "id": "RATING",
          "title": "Feedback 1 de 2",
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "TextHeading",
               "text": "Como foi sua experiência?"},
              {"type": "RadioButtonsGroup",
               "name": "rating", "label": "Avaliação",
               "required": true,
               "data-source": [
                 {"id": "5", "title": "Excelente"},
                 {"id": "4", "title": "Bom"},
                 {"id": "3", "title": "Regular"},
                 {"id": "2", "title": "Ruim"}
              ]},
              {"type": "Footer", "label": "Avançar",
               "on-click-action": {
                 "name": "navigate",
                 "next": {"type": "screen", "name": "COMMENTS"},
                 "payload": {}
              }}
            ]
          }
        },
        {
          "id": "COMMENTS",
          "title": "Feedback 2 de 2",
          "terminal": true,
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "TextArea", "name": "comments",
               "label": "Comentários",
               "required": false},
              {"type": "Footer", "label": "Enviar",
               "on-click-action": {
                 "name": "complete",
                 "payload": {
                   "rating": "${screen.RATING.form.rating}",
                   "comments": "${form.comments}"
                 }
              }}
            ]
          }
        }
      ]
    }

    A ação navigate leva o usuário à segunda tela com um payload vazio. A partir do Flow JSON v4.0, qualquer tela pode ler as entradas de outra tela com a sintaxe global ${screen.RATING.form.rating}, então a ação complete na última tela envia tanto a avaliação quanto os comentários.

    Agendamento de consultas (dinâmico, com endpoint)

    Um Flow dinâmico usa a ação data_exchange para solicitar ao seu servidor os horários disponíveis e depois os mostra em uma segunda tela:

    {
      "version": "7.3",
      "data_api_version": "4.0",
      "routing_model": {
        "BOOKING": ["SLOTS"],
        "SLOTS": []
      },
      "screens": [
        {
          "id": "BOOKING",
          "title": "Agendar horário",
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "DatePicker", "name": "date",
               "label": "Selecione uma data", "required": true},
              {"type": "Footer",
               "label": "Ver disponibilidade",
               "on-click-action": {
                 "name": "data_exchange",
                 "payload": {"date": "${form.date}"}
              }}
            ]
          }
        },
        {
          "id": "SLOTS",
          "title": "Escolha um horário",
          "terminal": true,
          "data": {
            "available_slots": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "id": {"type": "string"},
                  "title": {"type": "string"}
                }
              },
              "__example__": [
                {"id": "1", "title": "08:00"},
                {"id": "2", "title": "09:00"}
              ]
            }
          },
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "Dropdown", "name": "slot",
               "label": "Horários disponíveis", "required": true,
               "data-source": "${data.available_slots}"},
              {"type": "Footer", "label": "Confirmar agendamento",
               "on-click-action": {
                 "name": "complete",
                 "payload": {
                   "date": "${screen.BOOKING.form.date}",
                   "slot": "${form.slot}"
                 }
              }}
            ]
          }
        }
      ]
    }

    Quando o usuário seleciona uma data e toca no Footer, o Flow envia ao seu endpoint uma requisição POST criptografada com a data selecionada. Seu servidor descriptografa a requisição usando a sua chave privada RSA e AES-128-GCM, consulta os horários disponíveis e retorna uma resposta criptografada com a tela seguinte ("screen": "SLOTS") e um objeto data que contém available_slots. O usuário escolhe um horário, e a ação complete envia a data e o horário ao seu webhook. Envie este Flow com flow_action definido como "navigate" e a primeira tela definida como BOOKING, para que a abertura do Flow dispense uma chamada ao seu endpoint.

    Como projetar um Flow que as pessoas concluam?

    As boas práticas da Meta para Flows se concentram em manter cada tarefa curta e cada tela simples, para que os usuários terminem o que começaram. Para mensurar os seus próprios resultados, o Flows Builder no WhatsApp Manager mostra estatísticas de interação dos Flows publicados.

    Boas práticas documentadas pela Meta:

    • Mantenha cada tela com uma única tarefa e o Flow inteiro abaixo de 5 minutos.
    • Escreva um CTA que diga ao usuário exatamente o que acontece quando ele tocar no botão. Mantenha o texto do botão curto: a nossa documentação define um limite de 20 caracteres, sem emoji.
    • Use o componente certo para cada tipo de entrada: DatePicker para datas, Dropdown para 8 opções ou mais, RadioButtonsGroup para uma escolha única entre menos opções, CheckboxGroup para seleções múltiplas.
    • Planeje para o cache: quando um usuário conclui uma tela e avança, o WhatsApp armazena em cache os dados daquela tela. Um usuário que sai perde o que digitou na tela atual, então várias telas curtas colocam menos dados em risco do que uma tela longa.
    • Termine os Flows de várias etapas com uma tela de resumo, para que o usuário revise tudo antes de enviar.

    Para entender melhor como os Flows se encaixam nos seus processos de mensagens, veja o nosso guia de automação no WhatsApp.

    Quanto custam os Flows?

    A Meta cobra por mensagem entregue, então o custo de um Flow é o custo da mensagem que leva o botão dele.[9] Os planos da 360Dialog têm preço por número por mês e não listam cobrança separada para Flows. Se você envia o Flow dentro de uma mensagem de template, paga a tarifa da categoria desse template (marketing, utilidade ou autenticação), que varia por país.

    Se você envia o Flow como mensagem interativa em resposta a um usuário, ele sai dentro da janela de atendimento ao cliente de 24 horas. A partir de 1º de outubro de 2026, a Meta cobra essas respostas como mensagens de serviço, com a mesma tarifa das mensagens de utilidade e autenticação naquele mercado, e também cobra os templates de utilidade enviados dentro da janela.[10] As mensagens dos usuários, incluindo um Flow enviado por eles, são gratuitas. Para ver as tarifas atuais por mensagem em cada país, consulte a nossa página de preços.

    Empresas de SaaS e revendedores que querem oferecer Flows nos próprios produtos podem integrar o WhatsApp no seu SaaS com a Partner Platform da 360Dialog, que fornece a infraestrutura de API para implantações multi-cliente.

    Se você já quer criar seu primeiro Flow, o próximo passo é começar a usar a API com a 360Dialog e, se o seu Flow usar um endpoint, seguir as etapas de configuração do par de chaves na nossa documentação de Flows.

    Perguntas frequentes

    Posso enviar um Flow dentro de uma mensagem de template?

    Sim. Você anexa um Flow a uma mensagem de template adicionando um botão do tipo FLOW durante a criação do template. O botão identifica o Flow pelo ID ou pelo nome e indica a primeira tela quando a ação do botão é navigate. Quando o usuário toca no botão, o Flow abre dentro do chat. O próprio template passa pelo processo padrão de aprovação de templates do WhatsApp, então garanta que o conteúdo do template e o objetivo do Flow estejam de acordo com as políticas de comércio e de mensagens da Meta.

    O que você precisa para enviar um Flow?

    Você precisa de um número de telefone comercial registrado na WhatsApp Cloud API. Qualquer empresa pode começar a criar Flows no WhatsApp Manager e, para publicá-los e enviá-los, a Meta exige uma empresa verificada e alta qualidade das mensagens.

    Posso testar um Flow antes de publicar?

    Sim. O Flows Builder no WhatsApp Manager tem uma pré-visualização interativa que se comporta como um dispositivo real e envia requisições reais ao seu endpoint, se o Flow tiver um. Você também pode enviar o rascunho para um telefone de teste, pela opção Send do Builder ou pela API com o modo definido como draft. As mensagens de rascunho mostram um banner de aviso no dispositivo, e o telefone de teste precisa ter enviado uma mensagem ao seu número nas últimas 24 horas. Os Flows criados desde novembro de 2024 continuam editáveis após a publicação, pela API ou pelo Builder, e mantêm o mesmo Flow ID.

    O que acontece com os dados do usuário se ele fechar o Flow no meio?

    O WhatsApp armazena em cache os dados de uma tela assim que o usuário a conclui e avança para a próxima. Os dados digitados na tela atual, antes de o usuário tocar no botão do Footer, se perdem se ele sair. Por isso a Meta recomenda dividir formulários com vários campos em várias telas curtas, para que menos dados fiquem em risco se o usuário sair antes de terminar.

    Os dados são criptografados?

    Sim. Todos os dados trocados entre o Flow e o seu endpoint usam troca de chaves RSA de 2048 bits (OAEP-SHA256) combinada com criptografia AES-128-GCM do payload. A requisição recebida contém três campos: encrypted_flow_data, encrypted_aes_key e initial_vector. Você descriptografa a chave AES com a sua chave privada RSA e depois descriptografa o payload com AES-GCM. Sua resposta é criptografada com a mesma chave AES, usando um vetor de inicialização invertido. O guia completo de implementação da criptografia, com exemplos de código em seis linguagens, está na documentação para desenvolvedores da Meta.

    Fontes

    [1] Meta, “WhatsApp Flows,” developers.facebook.com/docs/whatsapp/flows. Accessed September 29, 2026.

    [2] Meta, “Flow JSON Reference,” developers.facebook.com/docs/whatsapp/flows/reference/flowjson. Accessed September 29, 2026.

    [3] Meta, “Components Reference,” developers.facebook.com/docs/whatsapp/flows/reference/components. Accessed September 29, 2026.

    [4] Meta, “Implementing Your Flow Endpoint,” developers.facebook.com/docs/whatsapp/flows/guides/implementingyourflowendpoint. Accessed September 29, 2026.

    [5] 360Dialog, “Flows,” docs.360dialog.com/docs/messaging/flows. Accessed September 29, 2026.

    [6] Meta, “Best Practices,” developers.facebook.com/docs/whatsapp/flows/guides/bestpractices. Accessed September 29, 2026.

    [7] Meta, “Changelog,” developers.facebook.com/docs/whatsapp/flows/changelogs. Accessed September 29, 2026.

    [8] Meta, “Sending a Flow,” developers.facebook.com/documentation/business-messaging/whatsapp/flows/guides/sendingaflow. Accessed September 29, 2026.

    [9] Meta, “Pricing on the WhatsApp Business Platform,” developers.facebook.com/docs/whatsapp/pricing. Accessed September 29, 2026.

    [10] Meta, “Upcoming Pricing Updates for Meta Business Agent, Service and Utility Messages,” developers.facebook.com/documentation/business-messaging/whatsapp/pricing/non-template-messages. Accessed September 29, 2026.

  • Nomes de usuário do WhatsApp: o que isso realmente significa para a sua empresa (2026)

    Nomes de usuário do WhatsApp: o que isso realmente significa para a sua empresa (2026)

    ARTIGO AO VIVO, ATUALIZADO REGULARMENTE. A Meta está lançando os nomes de usuário em fases ao longo de 2026. Atualizamos esta página sempre que uma nova informação é confirmada oficialmente. Última atualização: julho de 2026.

    A Meta está lançando os nomes de usuário do WhatsApp ao longo de 2026. Este artigo explica o que isso significa para os seus sistemas, para os seus clientes e o que você precisa fazer.

    TL;DR: os nomes de usuário do WhatsApp explicados

    Leia isto se você tem 60 segundos. Volte ao artigo completo quando estiver pronto para agir.

    • A Meta está introduzindo os nomes de usuário do WhatsApp. Os clientes poderão ocultar o número de telefone ao enviar mensagens para empresas.
    • Quando isso acontecer, você precisará usar um novo identificador chamado Business-Scoped User ID (BSUID) no lugar do número de telefone.
    • Para facilitar a transição e a compatibilidade entre BSUIDs e números de telefone, a Meta também lançou um recurso chamado Contact Book. Ele mapeia automaticamente os números de telefone dos clientes para os BSUIDs a partir dos eventos de conversa, mesmo antes de a adoção dos nomes de usuário começar, então a maior parte da sua base já fica protegida automaticamente.
    • O período de abril a junho foi uma janela de testes e adoção ao vivo. Os BSUIDs ficaram visíveis nos webhooks e os Contact Books começaram a montar os mapeamentos, mas a adoção dos nomes de usuário ainda não tinha começado. Esse foi o momento de entender a mudança, não de construir às pressas.
    • Nada quebrou até a adoção dos nomes de usuário começar, no final de junho de 2026, e mesmo assim apenas para conversas totalmente novas iniciadas por usuários que adotaram um nome de usuário.
    • A Meta também adicionou um botão Request Contact Info que permite pedir ao cliente para compartilhar o número de telefone dentro da conversa, para os fluxos que ainda precisam de um número.
    • A 360Dialog vai fornecer especificações completas, exemplos e suporte de implementação conforme o lançamento avança. Você não vai precisar resolver isso sozinho.
    • Os números de telefone não vão desaparecer. Os clientes atuais e o envio de mensagens ativas para números conhecidos não são afetados.

    O que de fato muda com os nomes de usuário do WhatsApp e por quê

    Durante anos, o WhatsApp funcionou com base em um princípio simples: o seu número de telefone é a sua identidade. Cada conta, cada conversa, cada interação comercial esteve ligada a um número.

    Isso está prestes a mudar de propósito, e por um bom motivo.

    Uma pesquisa da Meta mostrou que o controle sobre as informações pessoais é uma das maiores preocupações dos usuários ao usar o WhatsApp. Muitas pessoas não querem compartilhar o número de telefone com toda empresa para a qual enviam mensagens. Os nomes de usuário dão essa opção a elas.

    A partir de meados de 2026, os usuários podem escolher um nome de usuário (um identificador como @AliceWhitman) e usá-lo para enviar mensagens a empresas sem revelar o número de telefone. É opcional. A adoção será gradual. E a plataforma foi desenhada com um período de transição justamente para que as empresas consigam se adaptar sem interrupções.

    Na prática, isso significa que o seu sistema vai começar a receber um Business-Scoped User ID (BSUID) junto com os números de telefone e, mais adiante, apenas os BSUIDs depois que o usuário em questão adotar um nome de usuário. Entender as mudanças e como elas vão acontecer é justamente o objetivo deste guia.

    Duas coisas que você precisa entender primeiro

    Antes de entrar nos prazos e no que atualizar, dois conceitos precisam estar claros. Todo o resto se apoia neles.

    1. Nomes de usuário não são a mesma coisa que Display Names

    Este é o ponto de confusão mais comum, então vamos deixá-lo claro.

    O seu Display Name é o nome comercial que os seus clientes veem dentro da conversa do WhatsApp. Ele está ligado ao seu perfil comercial e ao seu número de telefone. Isso não vai mudar.

    Os nomes de usuário são diferentes. Para os usuários comuns do WhatsApp, eles são identificadores pesquisáveis, um novo ponto de entrada que permite encontrar e iniciar conversas com amigos e empresas sem precisar de um número de telefone. Pense neles como um @identificador no Instagram ou no Telegram.

    Um ponto importante para esclarecer: as empresas não poderão direcionar mensagens aos usuários por meio dos nomes de usuário. As mensagens comerciais vão continuar funcionando por identificadores da plataforma (números de telefone e BSUIDs). O que muda é como as conversas começam e qual identificador chega quando elas começam.

    Uma comparação lado a lado de como os nomes de usuário do WhatsApp são hoje e como serão no futuro.

    2. O que é um BSUID e por que ele importa?

    A forma mais simples de entender isso: o WhatsApp está deixando de lado a ideia de “número de telefone = identidade”.

    Quando um usuário adota um nome de usuário, o número de telefone dele deixa de ser compartilhado automaticamente com as empresas. Em vez disso, o WhatsApp envia um Business-Scoped User ID (BSUID), um identificador único que representa aquele usuário especificamente dentro do contexto do seu portfólio comercial.

    Três coisas para saber sobre os BSUIDs:

    • São únicos. Não existem dois usuários com o mesmo BSUID.
    • Têm escopo no seu portfólio comercial. O mesmo cliente tem um BSUID diferente em cada empresa com a qual interage. Isso é intencional: mantém a identidade estável dentro das suas conversas sem expor uma chave universal.
    • Aparecem em todos os webhooks a partir de 31 de março de 2026, independentemente de o usuário ter adotado ou não um nome de usuário. Isso dá tempo para você vê-los, testar o seu parsing e entender como eles são em payloads reais de webhook antes que qualquer coisa dependa deles.
    Comparação entre as diferentes opções de nome de usuário do WhatsApp. Hoje existe apenas o número de telefone e, no futuro, será possível escolher entre o número de telefone (sem adotar um nome de usuário) e adotar um nome de usuário.

    Como funciona a transição para os nomes de usuário

    Esta é a parte que mais importa para entender a sua exposição real e por que o cronograma é mais tranquilo do que pode parecer.

    Abril a junho de 2026: a janela de adoção

    Quando o Contact Book foi lançado em abril, ele começou a fazer algo valioso: armazena automaticamente o mapeamento entre os números de telefone dos seus clientes e os BSUIDs deles a cada interação que você tem com eles.

    Isso acontece em segundo plano, por padrão, para todas as empresas. Você não precisa construir nada para que funcione.

    Durante o período de abril a junho, os nomes de usuário ainda não estavam disponíveis para os usuários reivindicarem. Os BSUIDs ficaram visíveis nos seus webhooks para todos os eventos de mensagem e os Contact Books montaram os mapeamentos, mas os clientes ainda eram identificados pelo número de telefone nos seus fluxos atuais. Na prática, nada mudou nas suas mensagens durante esse período.

    Essa janela existiu para que você pudesse observar os BSUIDs em dados reais de webhook, entender como eles são e começar a planejar a sua implementação no seu próprio ritmo, com exemplos reais para usar como base.

    Na prática, isso significa: mesmo que você não tenha implementado nenhum tratamento de BSUID durante abril e maio, o seu Contact Book já vinha montando os mapeamentos para os seus clientes atuais. Sempre que você for implementar (em maio, junho ou depois), já vai ter uma base sólida de identificadores mapeados esperando por você.

    A partir de junho de 2026: quando a adoção dos nomes de usuário começa

    É quando os nomes de usuário ficam disponíveis para os usuários nos países de teste e, aos poucos, se expandem globalmente. À medida que os usuários adotam nomes de usuário, os números de telefone deles deixam de ser compartilhados automaticamente com as empresas para as quais enviam mensagens.

    Nesse momento, dois fluxos vão quebrar para os usuários que adotaram um nome de usuário caso o seu sistema não esteja tratando os BSUIDs:

    A ressalva importante: a adoção dos nomes de usuário será gradual. No lançamento, ela vai afetar uma pequena fração do seu tráfego de entrada. Para os clientes atuais cujos números de telefone já estão no seu Contact Book, a continuidade é preservada automaticamente.

    Um diagrama mostrando a transição do nome de usuário do WhatsApp

    O que não muda

    É igualmente importante saber o que permanece igual, independentemente da adoção dos nomes de usuário:

    • As mensagens de autenticação vão continuar sendo enviadas apenas para números de telefone, como hoje.
    • Os clientes que não adotaram um nome de usuário ainda poderão ser alcançados pelo número de telefone. Você também continua recebendo o número de telefone deles nos eventos de webhook normalmente.
    • O envio de mensagens ativas para números de telefone com os quais você interagiu no período de adoção continua funcionando: você pode continuar enviando mensagens de marketing, utilitárias e de autenticação para números conhecidos, graças ao Contact Book.

    O Contact Book: a sua rede de proteção na transição

    O Contact Book é o recurso que torna essa transição administrável e vem ativado por padrão para todas as empresas.

    A partir de abril de 2026, toda vez que você envia ou recebe uma mensagem com o número de telefone de um cliente, o WhatsApp armazena automaticamente o mapeamento entre esse número e o BSUID dele no seu Contact Book. Nenhuma ação é necessária da sua parte.

    O que isso significa na prática: se um cliente adotar um nome de usuário mais tarde, você ainda vai conseguir contatá-lo pelo número de telefone, já que o Contact Book terá o número dele mapeado para o BSUID em segundo plano. Os seus relacionamentos com clientes atuais ficam protegidos automaticamente. A Meta mantém o número de telefone de um cliente disponível para você em duas situações: quando você trocou uma mensagem ou chamada com esse número nos últimos 30 dias, ou quando o número já está armazenado no seu Contact Book. As entradas do Contact Book são mantidas até você desativar o recurso, então um relacionamento não se perde só porque um cliente ficou um tempo sem interagir.

    O único ponto de atenção: para que isso funcione, você precisa manter o Contact Book ativado. Ele vem ativado por padrão, e recomendamos deixá-lo assim. Você pode gerenciar essa configuração no Business Manager a partir de 16 de março de 2026, embora ele só comece a coletar dados quando os webhooks forem enriquecidos com o BSUID, em 31 de março de 2026.

    Para as situações que o Contact Book não cobre – um contato totalmente novo cujo número você nunca teve – a Meta adicionou um botão Request Contact Info. Em vez de torcer para que o cliente digite o número na conversa, você envia uma mensagem com o botão anexado (em um template ou como uma mensagem interativa), o cliente toca nele e o número de telefone dele volta para você em um webhook de contatos, junto com o BSUID. É a forma limpa de coletar um número quando um fluxo realmente precisa de um.

    2 cenários de como as coisas ficam antes e depois da introdução do Contact Book no WhatsApp

    O que fazer e quando

    Não existe um prazo único para todos. O momento certo depende da sua configuração e de quanto tráfego você espera de novos usuários que adotarem nomes de usuário no lançamento.

    Veja como pensar nisso:

    Se você quer se antecipar

    A partir de 31 de março, os BSUIDs vão aparecer nas respostas de webhook ao vivo. Este é o momento ideal para:

    • Ler o campo user_id nas suas respostas de webhook e registrar os valores. Não é preciso agir sobre eles ainda, apenas observar
    • Adicionar o BSUID como um campo nos perfis dos seus clientes, ao lado do número de telefone
    • Começar a mapear os BSUIDs para os registros existentes, para que o seu CRM esteja pronto quando a adoção dos nomes de usuário começar
    • Atualizar os fluxos de chatbot para solicitar um número de telefone pelo novo botão Request Contact Info, nos fluxos que dependem de ter um

    Se você ainda não está pronto para implementar

    Tudo bem. O Contact Book já protege a sua base de clientes atual por padrão. Você não está perdendo nada crítico durante a janela de adoção de abril a junho.

    A 360Dialog vai lançar especificações completas de implementação, exemplos reais de webhook e orientações passo a passo conforme o lançamento avança. Você não precisa implementar com base em payloads hipotéticos hoje. Vamos garantir que você tenha tudo o que precisa, com dados reais para usar como base, antes que isso realmente importe para os seus fluxos.

    O nosso compromisso: ficamos entre você e a complexidade deste lançamento para que você não precise lidar com ela. Vamos fornecer documentação, exemplos e suporte em cada etapa. Acompanhe esta página para ver as atualizações à medida que forem confirmadas.

    Uma nota para empresas que gerenciam múltiplos portfólios

    Os BSUIDs têm escopo em um portfólio comercial, não global. O mesmo cliente terá um BSUID diferente em cada portfólio com o qual interagir.

    Se você gerencia vários clientes em portfólios diferentes, isso afeta o mapeamento de identidade em escala. A solução são os BSUIDs principais (parent BSUIDs), um identificador compartilhado entre portfólios vinculados sob uma conta empresarial principal. Fale com o seu ponto de contato (POC) na Meta para configurar isso, caso se aplique à sua estrutura.

    Cronograma de lançamento

    Com base nas comunicações oficiais da Meta para parceiros e nos informes diretos da 360Dialog.

    • 16 de fevereiro de 2026 – BSUID visível em webhooks de teste pelo painel da Meta. Comece a se familiarizar com o formato.
    • 16 de março de 2026 – A configuração do Contact Book fica gerenciável no Business Manager. Mantenha ativada.
    • 31 de março de 2026 – Os BSUIDs aparecem em todas as respostas de webhook ao vivo. A janela de testes abre. Use esse período para observar, registrar e planejar.
    • Abril de 2026 – O Contact Book começa a registrar automaticamente os mapeamentos de número de telefone para BSUID. A sua base de clientes atual começa a construir a sua rede de proteção.
    • Maio de 2026 – A Meta confirma que o suporte da WhatsApp Business API para envio de mensagens via BSUID está a caminho, antes do lançamento completo.
    • 29 de junho de 2026 – As empresas podem reservar e reivindicar os próprios nomes de usuário. A adoção de nomes de usuário em nível de país começa, com os primeiros usuários adotando nos países de teste.
    • Julho de 2026 – O suporte completo para envio de mensagens diretamente para o BSUID de um cliente entra em operação. A Meta também adiciona o botão Request Contact Info, que permite pedir ao cliente para compartilhar o número de telefone dentro da conversa, em vez de esperar que ele o cole manualmente. Juntas, essas peças fecham o ciclo que se abriu quando os BSUIDs apareceram pela primeira vez nos webhooks.
    • Restante de 2026 – Lançamento global. A adoção dos nomes de usuário se expande tanto para usuários quanto para empresas.
    Um calendário mostrando como as empresas devem se preparar para os nomes de usuário do WhatsApp: Planejar no Q4 de 2025, Implementar no Q1 de 2026, Testar no Q2 de 2026 e ficar Pronto até julho de 2026, com os marcos do lançamento: testes de BSUID (jan-abr), início da adoção dos nomes de usuário (29 de junho) e o botão Request Contact Info (julho).
    Se o meu cliente adotar um nome de usuário, ainda posso enviar mensagens para ele?

    Sim. Se você já tem o número de telefone dele de uma conversa anterior, pode continuar enviando mensagens independentemente de ele ter adotado ou não um nome de usuário. O Contact Book preserva essa continuidade automaticamente, desde que esse número esteja armazenado no seu Contact Book ou você tenha interagido com ele nos últimos 30 dias.

    Meus clientes precisam fazer algo? E eu?

    Os nomes de usuário são opcionais para os usuários finais: ninguém é obrigado a adotar um. Para os parceiros que usam a WhatsApp Business Platform, será necessário atualizar os sistemas para tratar os BSUIDs, mas você tem um período real de transição para isso, com a 360Dialog fornecendo especificações e suporte conforme o lançamento acontece.

    Quais dos meus fluxos de mensagens podem quebrar, e quando?

    Dois fluxos podem quebrar para usuários que adotaram um nome de usuário: mensagens de anúncios CTWA e mensagens de atendimento recebidas. Isso só vale a partir do início da adoção dos nomes de usuário, em junho de 2026, e, no lançamento, a adoção será gradual. Para os clientes atuais cujos números de telefone estão no seu Contact Book, a continuidade é preservada automaticamente.

    O que é um BSUID e por que o meu sistema precisa tratá-lo?

    O BSUID é um identificador único que o WhatsApp atribui a cada usuário, com escopo no seu portfólio comercial. Quando um usuário adota um nome de usuário e deixa de compartilhar o número de telefone, o BSUID é o que o seu sistema recebe no lugar. Sem tratá-lo, você não consegue identificar nem responder a esses usuários.

    O Contact Book vem ativado por padrão. Preciso fazer alguma coisa?

    Na maioria dos casos, não. Mantenha-o ativado no Business Manager, você pode gerenciar essa configuração a partir de 16 de março de 2026. Enquanto estiver ativo, ele vai montar automaticamente o mapeamento de número de telefone para BSUID a partir de todas as interações com os seus clientes atuais. Nenhuma configuração adicional é necessária.

    Usamos anúncios click-to-WhatsApp. O que muda para nós?

    As conversas iniciadas por CTWA de usuários que adotaram um nome de usuário vão exigir que o seu sistema trate um BSUID no lugar de um número de telefone. Isso passa a ser relevante a partir de junho de 2026, quando a adoção dos nomes de usuário começa. A 360Dialog vai fornecer orientações específicas de implementação para esse cenário conforme o lançamento se aproxima.

    Como peço o número de telefone de um cliente se ele adotou um nome de usuário?

    Use o botão Request Contact Info da Meta. Você o anexa a um template ou a uma mensagem interativa e, quando o cliente toca nele, o número de telefone dele volta para você em um webhook de contatos, junto com o BSUID. É a forma recomendada de coletar um número quando um fluxo precisa dele e o Contact Book ainda não o tem.

    Construímos o nosso CRM em torno de números de telefone. Por onde começar?

    Comece adicionando um campo de BSUID aos perfis dos seus clientes e atualizando o parsing dos seus webhooks para ler o campo user_id. Não remova os números de telefone, você vai precisar dos dois. A 360Dialog vai publicar guias de integração de CRM passo a passo, com exemplos reais de payload, durante a janela de testes.

    Qual é o prazo real?

    A resposta prática: antes de a adoção dos nomes de usuário se tornar significativa nos seus mercados. Junho de 2026 é quando começam os testes em nível de país, e a adoção será gradual a partir daí. A janela de abril a junho foi pensada justamente para a implementação sem interrupções. A 360Dialog vai manter você informado sobre o que está acontecendo em cada mercado conforme o lançamento avança.

    Gerenciamos vários clientes em portfólios diferentes. O mesmo cliente terá um ID diferente em cada um?

    Sim. Os BSUIDs têm escopo por portfólio comercial, então o mesmo cliente vai aparecer com um BSUID diferente em cada portfólio. Se você precisa de um identificador compartilhado entre portfólios vinculados, a Meta oferece a solução de BSUID principal (parent BSUID). Fale com o seu ponto de contato (POC) na Meta.

    Se um cliente definir uma chave de nome de usuário (username key), ainda consigo alcançá-lo?

    Sim. As empresas que usam a WhatsApp Business Platform estão isentas das chaves de nome de usuário: o seu BSUID ou número de telefone já existente demonstra uma conexão estabelecida e dispensa a exigência da chave automaticamente.

  • Porque a 360Dialog define o padrão global em suporte para WhatsApp Business

    Porque a 360Dialog define o padrão global em suporte para WhatsApp Business

    Quando o WhatsApp é um canal crítico para o seu negócio, a qualidade do suporte do seu Business Solution Provider (BSP) não é apenas um diferencial – é um fator decisivo. Instabilidades, falhas na entrega de mensagens ou uma integração de API travada podem impactar diretamente a receita, o relacionamento com clientes e a continuidade operacional. Escolher o BSP certo significa escolher um parceiro que aparece quando mais importa.

    Na 360Dialog, construímos nossa infraestrutura de suporte em torno de um princípio central: o WhatsApp é business-critical, e nosso suporte precisa refletir isso.

    Resposta rápida quando realmente importa

    As médias do mercado para suporte SaaS podem chegar a 24 horas ou mais. Nós seguimos outro padrão.

    Nosso compromisso é conectar cada cliente e parceiro a um agente humano de suporte em menos de uma hora. Nos últimos 12 meses, nosso tempo médio de resposta humana foi de 34 minutos – bem abaixo desse benchmark: um indicador que acompanhamos continuamente para garantir que estamos evoluindo, não apenas mantendo o nível.

    Isso não é uma lógica de fila de tickets. Quando sua integração com o WhatsApp está fora do ar, esperar horas por uma primeira resposta não é aceitável. Uma média de 34 minutos significa que a maioria dos casos chega às mãos de uma pessoa antes mesmo de ter a chance de escalar.

    Atendimento 24 horas por dia, 7 dias por semana

    Problemas de API não respeitam horário comercial. Os clientes dos nossos usuários também não. Por isso, a 360Dialog mantém cobertura humana de suporte 24 horas por dia, 365 dias por ano.

    A qualquer momento, sempre há especialistas treinados em WhatsApp ativos na operação de suporte. Sem bots como primeira e última linha de defesa. Sem “retornamos na segunda-feira”. Pessoas reais, sempre disponíveis.

    Especialistas no assunto, não helpdesks generalistas

    Saber oferecer suporte para WhatsApp Business é tão importante quanto estar disponível. Nossos especialistas em WhatsApp são profissionais focados no ecossistema da Meta. Todos passam pelo treinamento interno intensivo da 360Dialog, reconhecido como um dos mais exigentes e completos do mercado, e são certificados como Meta Certified WhatsApp for Business Technical Implementation specialists – ou estão em processo ativo de preparação para essa certificação.

    Isso significa que, quando um cliente traz uma dúvida complexa sobre API ou compliance, ele fala com alguém que entende a arquitetura, as políticas e as nuances técnicas do WhatsApp – não com alguém lendo um script genérico.

    Suporte do seu jeito: acesso multicanal

    Clientes e parceiros diferentes trabalham de formas diferentes. Alguns preferem chat em tempo real. Outros se comunicam principalmente por email. Muitos dos nossos parceiros e clientes, naturalmente, querem resolver questões relacionadas ao WhatsApp pelo próprio WhatsApp.

    Nós oferecemos os três canais:

    Chat/WhatsApp: para resoluções rápidas e em tempo real.

    Email: para uma comunicação mais estruturada e documentada.

    Videoconferências: disponíveis para Premium Partners e para resolução de problemas com screenshare e apoio prático.

    O objetivo é eliminar qualquer fricção entre o problema e a solução, independentemente de como você prefere se comunicar.

    Suporte no seu idioma

    Problemas técnicos ficam ainda mais difíceis quando existe uma barreira de idioma. A equipe de suporte da 360Dialog oferece atendimento em cinco idiomas: inglês, português brasileiro, alemão, espanhol e russo – cobrindo os principais idiomas da nossa base global de clientes e parceiros.

    Sempre que possível, os clientes são direcionados a um agente fluente em seu idioma de preferência, porque acreditamos que comunicação clara também faz parte de uma resolução rápida.

    O que isso significa para clientes e parceiros

    Para empresas que usam o WhatsApp como canal de receita, e para parceiros que constroem produtos e serviços sobre a WhatsApp Business API, a qualidade do suporte do seu BSP influencia diretamente sua própria confiabilidade e reputação.

    O modelo de suporte da 360Dialog é construído com base em compromissos mensuráveis: tempo médio de resposta de 34 minutos, disponibilidade humana 24/7, expertise certificada no domínio, além de acesso multicanal e multilíngue.

    E há um ponto que nos diferencia ainda mais: nada disso tem custo premium. Não existem tiers de suporte, pacotes adicionais ou taxas ocultas para desbloquear tempos de resposta mais rápidos ou acesso a atendimento humano.

    Suporte de alto nível incluído por padrão – para todos os clientes e parceiros – dentro da política de precificação totalmente transparente da 360Dialog.