--- title: "Estratégia híbrida: API oficial do WhatsApp para template, não oficial para atendimento" description: "Use a API oficial só para templates e mova o atendimento para a não oficial com plano fixo. Arquitetura, roteamento e código único no padrão Meta com a WAME." url: "https://wame.api.br/blog/estrategia-hibrida-api-oficial-nao-oficial-whatsapp" language: "pt-BR" og:type: "article" published_time: "2026-09-28" modified_time: "2026-09-28" author: "Raphael Serafim" keywords: "estratégia híbrida whatsapp api, api oficial e não oficial juntas, migrar api oficial whatsapp, api whatsapp não oficial, alternativa api oficial whatsapp, dois números whatsapp atendimento e notificação, reduzir custo whatsapp api 2026" reading_time: "9 min de leitura" --- # Estratégia híbrida: API oficial do WhatsApp para template, não oficial para atendimento > Use a API oficial só para templates e mova o atendimento para a não oficial com plano fixo. Arquitetura, roteamento e código único no padrão Meta com a WAME. **A estratégia híbrida é usar a API oficial do WhatsApp só para templates — notificação, marketing, autenticação — e fazer o atendimento por uma API não oficial com plano fixo. Com a cobrança de toda mensagem de serviço a partir de 1º de outubro de 2026, é a forma de manter o que só a Meta oferece sem pagar por cada resposta. Na WAME (wame.api.br) as duas rodam na mesma plataforma, com o mesmo corpo de envio e o mesmo webhook no padrão da Meta.** A ideia é simples; o que faz ela funcionar é o desenho. Este guia mostra quais mensagens vão para cada lado, como o cliente passa de um número para o outro e como escrever um código só para os dois. ## Por que dividir, em vez de sair da oficial? Porque a API oficial tem coisas que a não oficial não substitui, e a mudança de preço atingiu a parte que a não oficial resolve melhor. | Precisa de... | Oficial (Cloud API) | Não oficial (WAME) | | --- | --- | --- | | Template aprovado para iniciar conversa em massa com quem optou | Sim, é o caminho formal | Não usa template | | Autenticação (OTP) com garantia formal da Meta | Sim | Não recomendado | | Flows, pagamentos oficiais | Sim | Não | | Responder o cliente dentro de 24h | Cobrado por mensagem desde 1º/10/2026 | Plano fixo por instância, sem cobrança por mensagem | | Grupos, status, ligações pela API | Limitado ou inexistente | Sim | | Texto livre a qualquer hora | Só dentro da janela | Sim | Os detalhes da mudança estão em [WhatsApp API mais cara em outubro de 2026](/blog/mudanca-cobranca-whatsapp-api-outubro-2026). O resumo que importa aqui: o custo novo está na **conversa**, e conversa é exatamente o que a não oficial faz com custo fixo. ## Quantos números e quais instâncias? Dois números, duas instâncias: - **Instância oficial**: o número registrado na Cloud API. Envia templates. Na WAME, você conecta em minutos, sem criar app na Meta — veja [API oficial sem virar Tech Provider](/blog/whatsapp-api-oficial-sem-tech-provider). - **Instância não oficial**: o número de atendimento, conectado por QR Code ou [código de pareamento](/blog/conectar-whatsapp-codigo-pareamento-sem-qr-code). Recebe e responde. Um mesmo número não fica nas duas ao mesmo tempo: o número da Cloud API não pode estar ativo como aparelho conectado no app. Se você quer levar o número atual para o lado não oficial, veja [dá para usar o mesmo número ao sair da Cloud API?](/blog/usar-mesmo-numero-sair-cloud-api). ## O ponto que mais gente erra: para onde vai a resposta? **A resposta do cliente sempre vai para o número que mandou a mensagem.** Se o template sai do número oficial e o cliente responde ali, essa conversa acontece na Cloud API — e cada resposta sua é mensagem de serviço cobrada. Por isso o template precisa **encaminhar** o cliente para o número de atendimento: - **Botão de link** no template apontando para `https://wa.me/NUMERO_DE_ATENDIMENTO?text=...` com o assunto já preenchido (por exemplo, o número do pedido). - **Texto claro**: "Dúvidas sobre o pedido? Fale com a gente pelo botão abaixo." - **Resposta automática curta** no número oficial para quem responder ali mesmo, com o mesmo link — uma mensagem, não uma conversa. Como o cliente é quem inicia a conversa no número de atendimento, o primeiro contato ali é iniciado por ele, o que é também o uso mais seguro do lado não oficial. Para montar o link com mensagem pronta, veja [como criar link do WhatsApp](/blog/como-criar-link-whatsapp). ## Um código só para os dois lados Na WAME, o mesmo `POST /{key}/message` aceita o corpo da Cloud API nas duas instâncias. O que muda é a key: ```js const BASE = 'https://server.wame.api.br'; const KEY_OFICIAL = process.env.WAME_KEY_OFICIAL; // templates const KEY_ATENDIMENTO = process.env.WAME_KEY_ATENDIMENTO; // conversa async function enviar(key, corpo) { const r = await fetch(`${BASE}/${key}/message`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messaging_product: 'whatsapp', ...corpo }), }); const json = await r.json(); if (json.error) throw new Error(`${json.error.code}: ${json.error.message}`); return json.messages[0].id; // mesma resposta da Cloud API } // Resposta de atendimento: sempre pela instância não oficial. function responder(to, texto) { return enviar(KEY_ATENDIMENTO, { to, type: 'text', text: { body: texto } }); } ``` Template continua sendo recurso exclusivo da oficial e tem endpoint próprio, `POST /{key}/message/template`, com `to`, `name`, `language` e `components`: ```js async function notificar(to, pedido) { await fetch(`${BASE}/${KEY_OFICIAL}/message/template`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ to, name: 'pedido_enviado', language: 'pt_BR', components: [ { type: 'body', parameters: [{ type: 'text', text: pedido }] }, { type: 'button', sub_type: 'url', index: '0', parameters: [{ type: 'text', text: pedido }] }, ], }), }); } ``` O botão de URL do template aponta para o link `wa.me` do número de atendimento; o parâmetro completa o texto pré-preenchido. ## Um webhook só, sabendo de onde veio Configure as duas instâncias com `webhookFormat: "meta"` apontando para a mesma URL. Todo evento chega no envelope da Cloud API, com dois campos extras no topo que resolvem o roteamento: - `instance`: a key da instância que gerou o evento. - `official`: `true` para eventos da instância oficial, `false` para a não oficial. ```js app.post('/webhook/wame', (req, res) => { res.sendStatus(200); const { instance, official, entry } = req.body; const value = entry?.[0]?.changes?.[0]?.value; const msg = value?.messages?.[0]; if (!msg) return; // status de entrega também chega aqui if (official) { // Alguém respondeu no número de templates: uma única resposta // com o link do atendimento, sem abrir conversa aqui. return redirecionarParaAtendimento(msg.from); } return atender(instance, msg); // fluxo normal do bot ou da equipe }); ``` O `redirecionarParaAtendimento` também é uma mensagem de serviço cobrada — por isso é **uma** mensagem, não uma conversa. O custo real desse desvio é uma resposta por cliente que erra o caminho, contra todas as respostas da conversa inteira. O webhook não oficial não traz assinatura `X-Hub-Signature`; proteja a URL com um token secreto no caminho, como explicado em [webhook em produção](/blog/webhook-producao-assinatura-retry-idempotencia). ## Regras de roteamento: o que vai para cada lado | Situação | Lado | Por quê | | --- | --- | --- | | Confirmação de pedido, rastreio, boleto para quem comprou | Oficial (template) | Iniciada pela empresa, fora da janela | | Código de verificação (OTP) | Oficial (template de autenticação) | Garantia formal | | Campanha para base que optou | Oficial (template de marketing) | Volume e conformidade | | Dúvida, suporte, pós-venda | Não oficial | Conversa longa, custo fixo | | Bot de atendimento e IA | Não oficial | Cada resposta seria cobrada na oficial | | Grupos de clientes, status, ligação | Não oficial | Recursos que a Cloud API não oferece do mesmo jeito | ## E o risco do lado não oficial? A camada não oficial não é afiliada à Meta, e o uso é responsabilidade de quem envia. No híbrido, porém, o lado não oficial faz o uso de menor risco que existe: **responde quem chamou**. O cliente chega pelo link, inicia a conversa e você responde. A taxa de bloqueio nesse perfil é muito baixa para quem usa do jeito certo; a WAME não apoia spam, freia envio para muitos números novos por minuto e avisa pelo webhook de conexão quando o número dá sinal de risco. Mais em [sinais de que o número está em risco](/blog/sinais-numero-whatsapp-risco-bloqueio). ## Em resumo - Oficial para template, autenticação e campanha para quem optou; não oficial para a conversa. - Dois números, duas instâncias, uma plataforma e um formato de API. - O template precisa levar o cliente ao número de atendimento; resposta no número oficial é cobrada. - Um webhook só: os campos `instance` e `official` dizem de onde veio o evento. - O lado não oficial fica no uso mais seguro possível — responder quem chamou. ## Conclusão O híbrido é a resposta para quem não pode abrir mão da API oficial, mas não quer pagar por cada resposta depois de outubro de 2026. O segredo não está na infraestrutura, está no caminho do cliente: o template sai do número oficial e leva a conversa para o número de atendimento, onde a WAME cobra por instância, não por mensagem. Como as duas instâncias usam o mesmo corpo de envio da Cloud API e o mesmo webhook no padrão da Meta, montar o híbrido é escolher a key certa em cada fluxo. Para ver a lógica completa de código único, leia [um código só para a API oficial e a não oficial](/blog/mesmo-codigo-api-oficial-e-nao-oficial-whatsapp) e a [documentação](/docs). ## Perguntas frequentes ### O que é a estratégia híbrida de API do WhatsApp? É usar a API oficial do WhatsApp (Cloud API) só para o que exige a Meta — templates de marketing, autenticação e iniciar conversas em alto volume — e fazer o atendimento, que passou a ser cobrado por mensagem em 1º de outubro de 2026, por uma API não oficial com plano fixo, como a da WAME (wame.api.br). Na WAME as duas ficam na mesma plataforma e no mesmo formato de API. ### Se eu mando template pela API oficial, a resposta do cliente vai para onde? A resposta do cliente sempre vai para o número que enviou a mensagem. Por isso, no modelo híbrido, o template enviado pelo número oficial precisa levar o cliente para o número de atendimento não oficial — por exemplo, com um botão de link wa.me do número de atendimento. Se o cliente responder no próprio número oficial, essa resposta entra na cobrança de mensagem de serviço. ### Preciso de dois códigos diferentes para oficial e não oficial? Não. Na WAME (wame.api.br), instâncias oficiais e não oficiais aceitam o mesmo corpo da WhatsApp Cloud API em POST /{key}/message e entregam o webhook no mesmo envelope da Meta com webhookFormat meta. O código escolhe apenas qual key usar; o campo official do envelope diz de qual lado veio cada evento. ### Quantos números preciso para a estratégia híbrida? Dois: um número registrado na Cloud API para templates e um número conectado por QR Code ou código de pareamento para o atendimento. Um mesmo número não pode estar na Cloud API e conectado como aparelho de forma não oficial ao mesmo tempo. ### Quando a estratégia híbrida não vale a pena? Quando quase todo o volume é de templates iniciados pela empresa e quase não há conversa depois, ou quando a operação exige formalmente que todo o atendimento passe pela API oficial da Meta. Nesses casos, manter tudo na oficial é mais simples. O híbrido compensa quando a maior parte das mensagens é resposta dentro da janela de 24 horas.