A Meta dividiu a WABA em duas: o que muda na API do WhatsApp

Se você administra um número do WhatsApp Business Platform, nas últimas semanas o Meta Business Suite mostrou este aviso: "Updates to your account". Ao fechá-lo, a tela da WABA não é mais uma só. Agora há duas abas, WhatsApp accounts e Messaging accounts.

A Meta mudou o modelo de dados da plataforma sobre a qual todos os provedores trabalham. A migração foi automática e terminou em meados de outubro de 2026. Nenhum ID mudou e nenhuma integração quebrou. O que mudou foi quem é dono do quê: o número fica sempre com a empresa, e os modelos e o faturamento passam para uma conta separada de cada provedor.

O problema do modelo antigo

Até agora, a WhatsApp Business Account (WABA) reunia tudo em uma só entidade: os números, os modelos de mensagem, a forma de pagamento, as assinaturas de webhooks e o acesso dos provedores. Na prática, um número só podia estar com um provedor.

Uma empresa que quisesse um provedor para disparos e outro para atendimento precisava de dois números, e o cliente os via como dois contatos diferentes na lista de conversas. Trocar de provedor exigia migrar o número, um processo que a própria Meta agora chama de "uma barreira natural para a troca".

A Meta já tinha testado uma solução intermediária, o Multi-Solution Conversations, em beta fechado e com requisitos altos. O novo modelo o substitui e o abre para todos.

O novo modelo: duas contas

A WABA foi dividida em dois contêineres com funções separadas.

WhatsApp account (WAAC). É a identidade da empresa, o que o usuário vê no WhatsApp. Contém:

• um único número de telefone (e, no futuro, um nome de usuário),
• o perfil da empresa,
• os catálogos de produtos.

A WAAC sempre pertence à empresa, nunca ao provedor, e é compartilhada com os provedores que a empresa escolher. Como cada uma tem um único número, várias WAACs podem ser agrupadas em uma hierarquia, com uma principal e outras vinculadas, que a Meta chama de "phone set".

Messaging account (conta de mensagens). É a operação de um provedor sobre esse número. Contém:

• os modelos de mensagem,
• a forma de pagamento,
• as assinaturas de webhooks.

Pode pertencer à empresa ou ao provedor, e cada provedor tem a sua. Um número pode ter várias contas de mensagens associadas.

Se você integra com a API, saiba que os IDs de WABA que já existiam agora identificam contas de mensagens. O waba_id que você tem guardado continua funcionando, mas aponta para a metade operacional, não para o número.

O que não mudou

Continuam iguais:

• os endpoints da Cloud API, com as mesmas rotas e os mesmos payloads (POST /<PHONE_NUMBER_ID>/messages),
• os IDs de número de telefone e os tokens de acesso,
• o fluxo de modelos: criar, editar e enviar para revisão,
• a assinatura de webhooks, que continua sendo feita no tópico whatsapp_business_account com o ID da conta de mensagens,
• o preço por mensagem.

Se a sua integração funcionava em 22 de setembro, funciona hoje.

O que os provedores compartilham

O faturamento se separa, mas três coisas continuam sendo do número e são divididas entre todos os provedores conectados:

• Qualidade. Fica na WAAC. Se um provedor manda disparos que os usuários bloqueiam ou denunciam, a qualidade cai para todos.
• Limite de mensagens. É calculado no nível do business portfolio e conta usuários únicos em 24 horas. Adicionar um segundo provedor não o duplica.
• Throughput. Continua sendo do número. Dois provedores enviando ao mesmo tempo dividem as mensagens por segundo.

A Meta aplicava as sanções conforme a origem. No esquema anterior, uma violação de modelos valia só para a conta que a cometia, e uma do número ou do portfolio valia para todas. A documentação nova não diz se isso continua. Se continuar, um modelo rejeitado afeta só o provedor que o criou, e um número bloqueado deixa todos sem serviço.

Quem recebe as mensagens recebidas

Se você opera um bot, precisa saber quem recebe o que o cliente escreve, e a documentação do novo modelo não diz. Ela explica que os webhooks são assinados por conta de mensagens e que os recibos de entrega (sent, delivered, read) voltam para o app que enviou a mensagem, mas não menciona as mensagens recebidas.

O precedente é o Multi-Solution Conversations, o esquema que o novo modelo substitui. Lá a Meta dizia explicitamente que todos os provedores com acesso ao número recebem todos os webhooks de entrada, e que a empresa coordena quem responde. Se isso se mantiver, dois bots conectados ao mesmo número vão responder ao mesmo cliente se ninguém definir quem cuida do quê.

Antes de conectar um segundo provedor, defina quem atende as consultas, quem faz disparos e quem nunca responde.

Faturamento: o token decide quem paga

Cada conta de mensagens tem a sua própria forma de pagamento, independente das outras. Cada mensagem é cobrada na conta de mensagens de quem a envia, e a Meta a identifica a partir do token de acesso:

• Se o token só consegue enviar de uma conta de mensagens naquele número, a Meta a escolhe sozinha. É o caso típico de um provedor com um cliente.
• Se consegue enviar de mais de uma, é preciso indicá-la com um parâmetro novo, messaging_account_id:

curl -X POST 'https://graph.facebook.com/v22.0/<PHONE_NUMBER_ID>/messages' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{
    "messaging_product": "whatsapp",
    "to": "<USER_PHONE>",
    "messaging_account_id": "<MESSAGING_ACCOUNT_ID>",
    "type": "template",
    "template": { "name": "<TEMPLATE_NAME>", "language": { "code": "pt_BR" } }
  }'

Um token alcança mais de uma conta quando uma empresa com integração própria adiciona um provedor para um caso específico, quando um cliente compartilha várias contas com o mesmo provedor, ou quando fatura em várias moedas, porque cada moeda precisa da sua própria conta de mensagens.

Se houver ambiguidade e você omitir o parâmetro, a Meta não garante o resultado: a mensagem pode ser cobrada na conta errada ou rejeitada. E se você usava paid_messaging_account_id, o nome antigo, tem até 31 de dezembro de 2026 para passar para o novo.

Para saber se uma conta de mensagens tem forma de pagamento:

curl 'https://graph.facebook.com/v22.0/<MESSAGING_ACCOUNT_ID>?fields=primary_funding_id' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'

Se não vier primary_funding_id, essa conta não pode enviar mensagens pagas.

Os modelos não viajam sozinhos

Os modelos pertencem à conta de mensagens onde foram criados e não são compartilhados. Se uma empresa troca de provedor, ou adiciona um, os modelos aprovados não aparecem na conta nova.

Há dois caminhos: criá-los de novo e enviá-los para revisão, ou copiá-los com a API de migração:

curl -X POST 'https://graph.facebook.com/v26.0/<DESTINATION_WABA_ID>/migrate_message_templates' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{ "source_waba_id": "<SOURCE_WABA_ID>", "page_number": 0 }'

A API só copia entre contas da mesma empresa na Meta, só copia modelos aprovados com qualidade verde ou sem classificação, e reinicia a qualidade e o tier do que copia. A Meta estima de duas a quatro semanas até esses modelos voltarem a render como antes. Trocar de provedor na semana anterior a uma campanha grande é má ideia.

Coexistência: o caso especial

Muitas empresas usam o app WhatsApp Business no celular e a API ao mesmo tempo, no mesmo número. Isso é a coexistência, e esses números também migraram para o novo modelo. Ao conectá-los, a Meta converte a WABA que já existia em uma conta de mensagens compatível e a compartilha com o provedor, em vez de criar uma para ele.

O calendário

Na fase 3 é preciso trocar o identificador na rota de /messages, o endpoint mais usado da plataforma. A Meta recomenda planejar isso durante 2027.

O que isso significa para a Trama e seus clientes

Na Trama, não chamamos a Cloud API do WhatsApp diretamente: o transporte fica a cargo do nosso provedor de mensagens. As mudanças de API de 2027 e 2028 são absorvidas nessa camada, e a fase 1 não exigiu nenhuma mudança do nosso lado.

Para quem usa a Trama, mudam três coisas:

• O número é seu, e agora a Meta deixa isso explícito. Nenhum provedor, nem nós, pode ficar com ele.
• Testar a Trama não exige mais mudar o número. Se você trabalha com outro provedor, pode nos conectar ao mesmo número. Combine antes quem responde as consultas, para que dois sistemas não respondam ao mesmo cliente.
• Outro provedor no seu número pode afetar você. Se ele manda mensagens que as pessoas bloqueiam, cai a qualidade do mesmo número que a Trama usa para atender as suas vendas.

Se você quer o lado dos custos, explicamos em quanto custa a WhatsApp Business API para uma agência de viagens. E se está se perguntando quantos números ter, em por que cada vendedor deveria ter o próprio WhatsApp mostramos por que distribuir o risco entre vários números é melhor do que concentrá-lo em um só.

O que levar daqui

• A WABA foi dividida em uma WhatsApp account, que é o número e sempre pertence à empresa, e uma conta de mensagens por provedor, com os modelos, o pagamento e os webhooks.
• Os IDs de WABA existentes agora são IDs de contas de mensagens.
• Vários provedores podem compartilhar um número, e com ele compartilham a qualidade, o limite diário e o throughput.
• Os modelos não são compartilhados entre contas de mensagens, e migrá-los reinicia a qualidade.
• Antes de 31 de dezembro de 2026, passe para messaging_account_id. Durante 2027, prepare a troca do ID do número pelo ID da WAAC para 2028.