Cloud API x On-Premises: a decisão que quase ninguém entende e que custa dinheiro todo mês

As diferenças que importam no dia a dia

Deixando de lado o vocabulário técnico, seis diferenças aparecem na operação:

• Quem mantém o servidor. Na Cloud API, a Meta. Na On-Premises, você ou o seu provedor — incluindo atualização de versão, que tinha prazo e virava urgência quando esquecida.
• Atualizações e recursos novos. Recursos novos chegam primeiro na Cloud API. Quem ficou no modelo antigo passou a receber menos, e mais tarde.
• Escala em pico. Na Cloud API, a capacidade é da Meta. Na On-Premises, disparo grande exigia dimensionar máquina, e falta de capacidade virava fila travada.
• Custo de infraestrutura. A Cloud API não tem custo de servidor. A On-Premises somava máquina, banco, backup e equipe de manutenção.
• Onde passam as mensagens. Na Cloud API, pela infraestrutura da Meta. Era esse o principal argumento de quem defendia o modelo antigo em setores com exigência de dado local.
• Suporte. Na Cloud API, problema de plataforma é problema da Meta. Na On-Premises, a primeira pergunta era sempre se o erro estava no seu contêiner.

Quem usava On-Premises e por quê

Três motivos sustentavam a escolha pelo modelo antigo, e vale entendê-los porque eles explicam a resistência de algumas empresas em migrar.

O primeiro era exigência regulatória ou interna sobre onde os dados trafegam e ficam armazenados, comum em bancos, saúde e setor público. O segundo era latência e integração com sistemas internos: empresas com ERP pesado e regras próprias preferiam ter o componente do WhatsApp perto do resto da arquitetura. O terceiro era simplesmente história — quem começou antes da Cloud API existir montou tudo naquele modelo e não teve motivo para mexer enquanto funcionava.

O que mudou é que os dois primeiros motivos perderam força com o tempo, à medida que a Meta ampliou controles e opções de processamento, enquanto o custo de continuar no modelo antigo subiu: menos recursos, menos suporte e um prazo de descontinuação correndo.

Como saber em qual você está hoje

A maioria das empresas não sabe, porque contratou um provedor e nunca perguntou. Três caminhos rápidos para descobrir:

• Pergunte diretamente ao provedor, por escrito: "meu número está em Cloud API ou On-Premises?". A resposta deve vir sem rodeios.
• Olhe o painel da Meta. No gerenciador de contas do WhatsApp Business, o número aparece vinculado à conta comercial, e a forma de configuração dá pistas claras.
• Observe os sintomas. Se recursos novos demoram a chegar, se houve algum aviso de atualização de versão do contêiner, ou se o provedor fala em "nosso servidor do WhatsApp", provavelmente é o modelo antigo.

Saber isso importa por um motivo prático: se você está na On-Premises, existe uma migração pela frente, e é melhor planejá-la do que ser pego por um prazo.

Como funciona uma migração

Migrar de On-Premises para Cloud API não é trocar de número nem começar do zero, mas também não é um botão. O que acontece, em linhas gerais:

• o número é migrado dentro da mesma conta comercial, mantendo o mesmo telefone para o cliente;
• os templates aprovados são vinculados à conta, não ao servidor, e seguem disponíveis;
• a integração precisa apontar para o endereço novo, e o webhook precisa ser reconfigurado;
• existe uma janela curta de indisponibilidade durante a troca, que precisa ser combinada com a operação;
• a qualidade e o limite de envio do número acompanham a conta, não o servidor.

O ponto de atenção maior é o histórico de conversas. Ele vive no sistema que você usa, não na API — e é exatamente por isso que a escolha do sistema importa mais do que a escolha da hospedagem. Empresa que atendia direto pela API, sem CRM, costuma descobrir na migração que não tem histórico nenhum para levar.

O que não muda entre os dois modelos

Essa é a parte que mais surpreende quem espera que a Cloud API resolva problemas que não são dela. Continuam exatamente iguais nos dois modelos:

• As regras da Meta. Template aprovado para iniciar conversa, janela de atendimento, categorias de mensagem e política de uso valem igual.
• A cobrança por conversa. O modelo de preço da Meta é o mesmo, e não depende da hospedagem.
• Qualidade e limite de envio. O tier do número e a classificação de qualidade seguem a conta, e não melhoram por trocar de modelo.
• Bloqueio e banimento. Quem denuncia é o cliente, e a consequência é a mesma.
• Opt-in. Continuar precisando de permissão para enviar não é detalhe técnico, é regra.

Ou seja: se o seu problema hoje é template rejeitado, número com qualidade baixa ou disparo barrado, mudar de Cloud API para On-Premises ou o contrário não resolve nada.

Segurança e dados: o que cada modelo realmente entrega

Esse era o argumento mais forte a favor da On-Premises e continua sendo o mais mal compreendido. A ideia intuitiva é que manter o servidor em casa significa que os dados "não saem da empresa" — e isso nunca foi verdade. Em qualquer dos dois modelos, a mensagem trafega pela rede do WhatsApp, é entregue pela infraestrutura da Meta ao aparelho do cliente e está sujeita às políticas da plataforma.

O que mudava na On-Premises era onde ficava o componente que intermediava o envio e onde o conteúdo era processado nesse trecho específico. Para setores com exigência regulatória sobre processamento local, isso fazia diferença jurídica real. Para a esmagadora maioria das empresas, não fazia diferença nenhuma na prática, e a sensação de controle vinha acompanhada de um risco maior: servidor mal mantido, sem atualização e com backup improvisado é menos seguro do que infraestrutura administrada.

Hoje, a conversa útil sobre segurança mudou de lugar. Ela não é mais sobre a hospedagem da API, e sim sobre quem tem acesso às conversas no sistema que você usa: existe controle de permissão por usuário, o atendente consegue exportar a base inteira, o que acontece quando um vendedor sai da empresa, quem consegue ver conversa de outro atendente, e como é feito o registro de quem fez o quê. É aí que vazamento acontece de verdade — no acesso indevido de quem já está dentro, não no trecho de rede entre você e a Meta.

Por que o provedor importa mais que a hospedagem

Do ponto de vista de quem usa, a hospedagem da Meta é invisível. O que se vê todo dia é o que está em cima dela: a tela de atendimento, o histórico, a automação, os relatórios, a velocidade de suporte, a estabilidade das integrações.

Duas empresas podem estar na mesma Cloud API e ter experiências opostas, porque uma tem um sistema que guarda conversa, distribui lead, automatiza resposta e mostra número de resultado, e a outra tem uma caixa de entrada genérica que perde mensagem quando o navegador fecha. A hospedagem é a mesma; o negócio não.

Na hora de escolher, as perguntas que realmente mudam o resultado são: o histórico é meu e posso exportar; quantos atendentes cabem no mesmo número; existe automação de verdade ou só resposta automática; o sistema mostra tempo de primeira resposta e conversão; e quanto tempo o suporte leva para responder quando o disparo para numa sexta-feira à noite.

Coexistência, QR Code e por que isso é outra conversa

Uma confusão frequente mistura três coisas diferentes: Cloud API, On-Premises e as soluções não oficiais baseadas em leitura de QR Code. As duas primeiras são hospedagens da API oficial. A terceira não é API oficial nenhuma — é um software que se conecta ao WhatsApp como se fosse um celular pareado.

A diferença prática é grande. Na API oficial, existe contrato, template aprovado, cobrança por conversa, suporte e previsibilidade. Na conexão por QR Code, não existe aprovação prévia de mensagem nem custo por conversa, o que atrai muita gente, mas também não existe garantia nenhuma: o número pode ser bloqueado a qualquer momento, sem aviso e sem recurso, e o comportamento de disparo é justamente o que mais dispara bloqueio.

Existe ainda a coexistência, que permite usar o aplicativo WhatsApp Business e a API oficial no mesmo número, com regras próprias definidas pela Meta. Ela resolve um problema específico — manter o histórico e o uso no celular enquanto a empresa entra na API — e não substitui a decisão de hospedagem.

A leitura correta é enxergar dois eixos independentes. Um é o canal: oficial ou não oficial. O outro, dentro do oficial, é a hospedagem: Cloud ou On-Premises. Misturar os dois eixos leva a decisões ruins, como escolher QR Code achando que é "a versão barata da API oficial" quando, na verdade, é uma categoria diferente, com risco diferente e sem nenhuma das garantias que fazem uma empresa escolher o caminho oficial.

O custo real de cada modelo

Comparação para uma operação média, com um número e cerca de seis mil conversas por mês:

• Cloud API: custo das conversas cobrado pela Meta + mensalidade do sistema de atendimento. Infraestrutura: zero.
• On-Premises: custo das conversas cobrado pela Meta + mensalidade do sistema + servidor e banco de dados + backup + tempo de equipe técnica para atualização e monitoramento.

Em uma operação real com servidor dedicado modesto, backup e cerca de quatro horas mensais de trabalho técnico, o modelo antigo adicionava algo entre R$ 600 e R$ 1.400 por mês de custo que simplesmente não existe na Cloud API — sem entregar nada a mais para quem atende. Para empresas com exigência específica de processamento de dados, esse custo se justificava. Para todas as outras, era custo puro.

Os erros mais comuns nessa decisão

• Achar que a hospedagem resolve problema de qualidade de número ou de template rejeitado.
• Escolher provedor pelo preço da mensalidade sem perguntar se o histórico é exportável.
• Adiar a migração da On-Premises até virar urgência com prazo.
• Migrar sem reconfigurar o webhook e ficar sem receber mensagem por dias.
• Não combinar a janela de indisponibilidade com a equipe de atendimento.
• Confundir Cloud API com o aplicativo WhatsApp Business, que são coisas completamente diferentes.

Por onde começar

Se você está começando agora, a resposta é simples: Cloud API, com um provedor que entregue histórico seu e exportável. Se você já opera, descubra por escrito em qual modelo está; se for On-Premises, peça ao provedor o plano de migração com data, janela e responsável por reconfigurar o webhook; e aproveite a migração para revisar o que realmente importa — se o seu sistema guarda o histórico, se a automação funciona e se você consegue medir tempo de resposta e conversão. A hospedagem é decisão de uma vez; o sistema em cima dela é o que você usa todo dia.