A WhatsApp Business Platform recebeu um pacote de novidades que mexe direto no dia a dia de quem cria, integra e mantém soluções com as APIs do WhatsApp. Tem documentação “next-gen” (mais moderna e prática), um repositório público no GitHub com especificações OpenAPI, e uma mudança importante na experiência de chamadas via WhatsApp Business Calling API, especialmente para quem usa mais de um aparelho no mesmo número.
Vou passar por tudo de forma bem direta, com exemplos e cenários de uso. Onde eu mencionar “código”, vou mostrar trechos prontos para você entender como isso costuma ser consumido na prática (sem inventar endpoints ou parâmetros além do que foi informado; aqui o foco é em como usar os recursos anunciados).
1) Documentação “next-gen” da WhatsApp Business Platform (em todos os idiomas)
A principal mudança é que a documentação de desenvolvedor foi relançada em uma versão “next-gen”, já disponível para as APIs do WhatsApp em todos os idiomas. Isso costuma significar menos fricção para começar e mais velocidade para encontrar o que você precisa quando está no meio de uma integração.
O endereço informado para acessar a visão geral é este:
- WhatsApp Business Platform Developer Documentation: https://developers.facebook.com/documentation/business-messaging/whatsapp/overview
O que mudou na prática (destaques anunciados)
Streamlined Onboarding (onboarding mais enxuto): foram adicionadas novas páginas de entrada, visões gerais e guias de “get started”. A ideia aqui é reduzir aquele caminho confuso de “por onde começo?” e organizar os primeiros passos de forma mais previsível.
Rapid Integration (integração mais rápida): entram experiências de “Hello World”, incluindo um bot ativado por QR code e um novo app de exemplo. Na prática, isso ajuda quem quer validar rapidamente:
- se as credenciais e o ambiente estão corretos;
- se a comunicação com a API está funcionando;
- qual é o fluxo mínimo para dar o primeiro passo sem construir tudo do zero.
Enhanced Discoverability (melhor encontrabilidade): melhorias de navegação e busca dentro da documentação. Isso normalmente economiza bastante tempo quando você precisa alternar entre visão geral, referência de API, exemplos e notas de comportamento.
API reference baseada em OpenAPI Spec: a referência passa a ser construída a partir de OpenAPI. O anúncio destaca quatro ganhos bem práticos:
- “playgrounds” interativos para testar;
- exemplos de código em múltiplas linguagens;
- texto otimizado para LLM (ou seja, mais fácil de ferramentas de IA “entenderem”);
- referências com possibilidade de “copiar e colar” para acelerar a integração.
Um ponto importante de roadmap: foi informado que mais recursos serão adicionados e que a expansão para Business Messaging APIs está prevista para 2026.
Exemplos práticos de como essa documentação ajuda (sem “mágica”)
Na rotina, uma doc baseada em OpenAPI e com playground costuma destravar três cenários bem comuns:
- Prototipar rápido: você testa a chamada no playground antes de abrir o editor e escrever código.
- Padronizar integração: como o contrato é formal, fica mais fácil alinhar time de backend, mobile e QA.
- Evitar retrabalho: exemplos multi-linguagem reduzem erros bobos de formato e headers.
Mesmo sem entrar em endpoints específicos (porque isso não foi fornecido aqui), o fluxo prático costuma ser: abrir a visão geral, seguir um “get started”, rodar o “Hello World” (QR e app de exemplo) e, daí, ir para a referência gerada por OpenAPI para construir as chamadas reais.
2) Lançamento público do repositório OpenAPI no GitHub
Outra novidade grande é que a Meta lançou publicamente o repositório de OpenAPI no GitHub. Isso é bem relevante porque transforma documentação em “contrato de máquina”: ferramentas conseguem ler, validar e até gerar código a partir disso.
Link fornecido:
- Meta OpenAPI Github Repository: https://github.com/facebook/openapi
Escopo de APIs incluídas (conforme anunciado)
- WhatsApp Business Platform
- Cloud API
- MM Lite API
- Business Management
Destaques anunciados do repositório
Arquivo .yaml unificado: foi destacado que existe um “unified .yaml file” fácil de navegar, pensado para consumo por negócios e com contratos legíveis por máquina. Em termos práticos, um único arquivo (ou um conjunto bem organizado) tende a facilitar auditoria, versionamento e automação.
Formato claro e padronizado: padronização acelera integrações porque reduz interpretações ambíguas e facilita comparar versões (o que mudou, o que foi removido, o que foi adicionado).
Compatibilidade nativa com ferramentas enterprise: o anúncio cita compatibilidade com ferramentas padrão do mercado, como Postman e Swagger. Isso ajuda em:
- importar a spec e testar chamadas rapidamente;
- gerar coleções e rotinas de testes;
- documentar internamente usando o mesmo contrato.
Redução de tempo de suporte: com documentação mais autoatendível, tende a diminuir o número de dúvidas repetidas e o tempo para resolver incidentes de integração.
Geração de SDK: o anúncio diz que isso “enabled SDK generation” para facilitar onboarding em várias linguagens. Em termos de prática, quando a spec está bem definida, você consegue gerar um cliente e padronizar:
- como autentica;
- como serializa/deserializa payloads;
- como trata erros;
- como organiza métodos por recurso.
Exemplos de uso com “código” (voltado a consumo de OpenAPI)
A seguir, exemplos genéricos e profissionais de como uma equipe costuma usar um arquivo OpenAPI em .yaml. Eles não assumem endpoints específicos do WhatsApp (porque não foram incluídos no conteúdo), mas mostram o “como fazer” com o que foi anunciado: a existência do contrato em GitHub e a compatibilidade com ferramentas do ecossistema.
Exemplo 1: validação local de uma spec (.yaml) antes de adotar no time
Objetivo: garantir que o arquivo OpenAPI está bem formado e pronto para ser importado em ferramentas.
Como era: muitas equipes dependiam só de páginas de doc e exemplos soltos, com risco de divergência.
Como fica: um contrato central ajuda a automatizar checagens e padronizar.
Exemplo 2: importação em ferramentas compatíveis (ex.: Swagger/Postman)
Objetivo: navegar pelos recursos, testar requisições e compartilhar coleções com o time.
Na prática: você pega o .yaml do repositório e importa na ferramenta para gerar a interface de testes.
Como o anúncio só cita as ferramentas e o repositório (sem um caminho exato do arquivo dentro do repositório), o passo a passo real é: acessar https://github.com/facebook/openapi, localizar a especificação da WhatsApp Business Platform e importar o .yaml no seu ambiente de testes.
Exemplo 3: geração de SDK a partir de OpenAPI
Objetivo: criar um cliente de API consistente para o time usar, reduzindo erros de integração.
Observação: a geração depende do arquivo .yaml e de uma ferramenta de geração escolhida pela equipe. O anúncio informa que o repositório habilita esse caminho.
O benefício aqui é menos “código manual repetitivo” e mais consumo padronizado, principalmente em times com múltiplos serviços e linguagens.
3) Atualização na WhatsApp Business Calling API: mais opções de chamada para usuários
Agora, uma mudança bem direta e que impacta operação: usuários do WhatsApp que usam múltiplos telefones vinculados à mesma conta passam a ter uma experiência de chamada mais flexível com negócios que usam a WhatsApp Business Calling API.
O que foi anunciado:
- Negócios que usam a WhatsApp Business Calling API agora podem receber chamadas de até quatro telefones vinculados.
- Isso significa: um telefone principal + até três telefones companheiros.
Como era antes vs. como fica agora
Antes: somente o telefone principal vinculado à conta do WhatsApp podia ser usado para fazer chamadas iniciadas pelo usuário para negócios habilitados via API. Se a pessoa estivesse usando um telefone companheiro, precisava esperar o principal ficar disponível para conseguir ligar.
Agora: chamadas iniciadas pelo usuário para negócios via WhatsApp Business Calling API passam a funcionar também a partir dos telefones companheiros, replicando a experiência que usuários já conhecem ao ligar para empresas que usam o app WhatsApp Business.
Em termos bem do dia a dia, isso reduz fila, evita “telefone ocupado” e melhora a chance de contato no primeiro intento, especialmente para times pequenos que revezam aparelhos.
Precisa fazer algo para ativar? ✅
Não. Foi informado que não é necessária nenhuma ação por parte de parceiros de chamadas, empresas finais ou usuários do WhatsApp para aproveitar a atualização.
Limitação importante (nota do anúncio) ⚠️
Mesmo com essa melhoria, chamadas iniciadas pelo negócio (ou seja, business-initiated calls) ainda só podem ser recebidas no telefone principal da conta do WhatsApp.
O anúncio também deixa claro que permitir que telefones companheiros recebam essas chamadas iniciadas pelo negócio está no roadmap, então deve haver uma atualização futura sobre isso.
Cenários práticos dessa mudança na Calling API
- Pequena empresa com 1 número e vários atendentes: antes, o atendente com o aparelho principal virava “gargalo”. Agora, usuários conseguem iniciar chamadas mesmo se o atendente estiver com um aparelho companheiro.
- Atendimento em turnos: reduz dependência de “passar o telefone principal” fisicamente ou ficar preso a um único dispositivo para receber chamadas iniciadas pelo usuário.
- Experiência consistente: a atualização iguala a sensação para o usuário final com o que já existe quando ele liga para empresas no app WhatsApp Business.
Fechando: o que muda daqui pra frente
No conjunto, a mensagem é clara: a Meta está empurrando a WhatsApp Business Platform para um modelo mais moderno de documentação e integração, com referência baseada em OpenAPI, melhor onboarding, exemplos de “Hello World” para acelerar testes e, ao mesmo tempo, melhorias concretas na experiência do usuário final em chamadas via WhatsApp Business Calling API.
Se você desenvolve ou mantém integrações, os dois links informados viram ponto de partida obrigatório: a documentação oficial para entender fluxos e a base OpenAPI no GitHub para padronizar ferramentas, contratos e automações.
- Documentação: https://developers.facebook.com/documentation/business-messaging/whatsapp/overview
- OpenAPI no GitHub: https://github.com/facebook/openapi
E, do lado operacional, a mudança das chamadas já melhora a vida de quem usa múltiplos aparelhos, sem exigir nenhuma ação para começar a valer. ✅