7 razões pelas quais o Meta rejeita seus modelos do WhatsApp

Aproximadamente 1 em cada 3 modelos do WhatsApp Business API é rejeitado na primeira revisão. Não é que o Meta seja arbitrário: ele rejeita por regras concretas — algumas sempre existiram, outras chegaram nos últimos 12 meses e ainda surpreendem equipes que operam WABA há anos.

Como parceira Gupshup, a AsisteClick gerencia centenas de modelos ativos em contas de clientes na LATAM. Vemos rejeições todos os dias e já catalogamos os padrões que as disparam. Este guia documenta os 7 erros mais comuns que veremos em 2026, com exemplos concretos do que é rejeitado, por quê e como escrever a versão que passa.

Antes dos 7 erros, um esclarecimento sobre o contexto que mudou: desde 9 de abril de 2025, o campo allow_category_change passou a ser o comportamento padrão. Isso significa que, se você enviar um modelo como UTILITY e o Meta detectar tom promocional, ele o reclassifica automaticamente para MARKETING — e o custo por mensagem sobe entre 5× e 7× dependendo do país. A aprovação é mantida, mas a operação fica rodando em uma categoria que você não escolheu.

Somam-se a isso as novas regras rígidas — limite de 550 caracteres no corpo, máximo de 10 emojis, proibição de modelos duplicados — que rejeitam automaticamente sem revisão humana. Conhecer essas regras antes de redigir é o que separa uma operação que aprova 5 modelos em um dia de outra que passa uma semana iterando com apelações.

Como funciona a aprovação de modelos em 2026

Cada modelo passa por duas camadas de revisão:

1. Revisão automática — verifica formatação (variáveis, comprimento, caracteres, emojis), categoria declarada vs conteúdo detectado, linguagem e proibições rígidas. Essa camada rejeita em segundos. É onde caem 70% das rejeições que vemos.
2. Revisão humana ou assistida por ML — verifica contexto, linguagem promocional sutil, intenção da mensagem, abuso de placeholders. Demora entre 2 minutos e 24-48 horas.

Uma vez aprovado, o modelo não fica blindado. O Meta continua avaliando como os usuários recebem cada envio. Se a taxa de bloqueios ou denúncias subir, o modelo pode entrar em estado PAUSED, depois em pausa mais longa, e finalmente ficar DISABLED de forma permanente. Voltamos a isso no final.

Razão 1: categoria errada (UTILITY vs MARKETING)

Essa é a razão #1 que vemos hoje. Até o início de 2025, era possível "negociar" a categoria: marcar como UTILITY uma mensagem tecnicamente promocional para pagar a tarifa mais barata. Desde abril de 2025, esse atalho fechou.

O que mudou: o campo allow_category_change agora é default em cada submissão. Se você declara UTILITY mas o texto contém promoção, desconto, recomendação de produto ou linguagem persuasiva, o Meta aprova o modelo mas o move para MARKETING. Você paga a tarifa de marketing sem ter escolhido isso conscientemente.

O que se qualifica como UTILITY (estrito):

• É resposta a uma ação do usuário (compra, reserva, registro, pagamento iniciado)
• É informação essencial sobre a conta (mudança de status, alerta de segurança, fatura emitida)
• Não tem linguagem persuasiva: não propõe uma compra, não sugere um produto, não convida a uma promoção

Exemplo que é reclassificado para MARKETING:

Oi Juan, seu pedido #1234 foi despachado. Aproveite 20% de desconto na sua próxima compra com o código RETURN20. Chega em 48h.

A primeira frase é UTILITY pura. A segunda contém uma oferta. O Meta detecta o cross-sell e reclassifica o modelo inteiro.

Versão que é aprovada como UTILITY:

Oi Juan, seu pedido #1234 foi despachado em 30/04 às 14:32. Chega em 48h. Acompanhe aqui: {{1}}.

E quanto ao custo? Nas tarifas de abril de 2026, a diferença é tangível: um modelo MARKETING na Argentina custa cerca de USD 0,061 por mensagem, enquanto um UTILITY fica em torno de USD 0,011 — e, se entrar na janela de serviço de 24 horas (depois de uma mensagem do usuário), um UTILITY é grátis. A 50.000 envios mensais, é a diferença entre USD 3.050 e USD 0.

Razão 2: variáveis mal formatadas

Essa razão rejeita na camada automática e por isso é uma das mais frustrantes — o sistema não te explica o detalhe, apenas diz INVALID_FORMAT.

As regras concretas:

• As variáveis são nomeadas {{1}}, {{2}}, {{3}} e devem ser sequenciais sem saltos. Pular de {{1}} a {{3}} é rejeição automática.
• Não podem estar no início nem no final da mensagem. Um modelo que começa com {{1}}, tu pedido… ou termina com …tu link es {{1}} não é aprovado.
• Não podem ficar coladas. {{1}}{{2}} é rejeição.
• Sem caracteres especiais dentro: {{0}}, {{01}}, {{1.}}, {{ 1 }} são todos inválidos.
• Densidade mínima de contexto: cada variável precisa de aproximadamente 3 palavras de texto ao redor. Um modelo com 5 variáveis e 10 palavras de texto é rejeitado por "abuse potential".

Exemplo de rejeição por densidade baixa:

Oi {{1}}, seu pedido {{2}} chega {{3}} em {{4}} com código {{5}}.

Muitas variáveis para tão pouco contexto. O Meta interpreta que o modelo pode ser usado para spam genérico mudando os valores.

Versão que passa:

Oi {{1}}, seu pedido número {{2}} chega em {{3}}. Vai para o endereço cadastrado e o entregador vai ligar para o telefone que temos em arquivo. Código de rastreamento: {{4}}.

Cinco palavras por variável, contexto claro, nenhum placeholder no início ou no final.

Razão 3: conteúdo vago ou reutilizável para spam

O segundo grande filtro da revisão humana é a "intenção clara". Um modelo que serve para qualquer coisa — tão genérico que um spammer pode reutilizá-lo só trocando as variáveis — é rejeitado com o motivo "lacks context" ou "vague content".

Exemplos de modelos que são rejeitados:

• Recordatorio: {{1}} — genérica demais.
• Hola {{1}}, te tenemos noticias — sem propósito declarado.
• {{1}}, hacé click acá: {{2}} — padrão clássico de phishing.

Como consertar: dar contexto suficiente para que o propósito seja inequívoco antes de ler a variável.

• ❌ Recordatorio: {{1}}
• ✅ Hola {{1}}, te recordamos que tu turno con el doctor {{2}} es mañana a las {{3}} en nuestra sede de {{4}}.

A regra mental que usamos ao redigir: se um modelo pode servir para um banco, uma clínica e um eCommerce sem mudanças, está genérico demais.

Razão 4: linguagem promocional agressiva

A camada de revisão humana penaliza o tom de spam clássico. Não basta que o conteúdo seja factualmente promocional (isso a categoria MARKETING já cobre) — a linguagem também tem que ser proporcional.

Frases que disparam rejeição ou reclassificação:

• "Última chance!" — urgência falsa.
• "Você não pode perder." — exagero.
• "Se não responder em 24 horas, perde o benefício." — ameaça.
• "Clique JÁ antes de acabar." — coerção.
• "A oferta MAIS LOUCA do ano." — claim sem sustentação.
• "Só para você, exclusivo." — combinado com descontos genéricos.
• Maiúsculas mantidas em blocos. OFERTA EXCLUSIVA HOY é rejeitado.

Como redigir marketing aprovável:

• Mencionar o desconto concreto sem pressão: "20% off na sua próxima compra até 15/05."
• Identificar o destinatário pela sua relação real, não por bajulação: "Como cliente da {{1}}, você acessa…"
• Dizer o que a promoção oferece e deixar o usuário decidir, sem ameaças nem urgência inflada.

O Meta é bem consistente: um modelo MARKETING sóbrio com desconto concreto e opt-out claro passa de primeira. Um com três sinais de exclamação e "última chance" entra em revisão humana e volta rejeitado.

Razão 5: links proibidos ou suspeitos

Essa razão é subestimada. O Meta tem uma lista negra de padrões de link que não são aprovados — não pelo domínio em si, mas pelo padrão.

Links que são rejeitados:

• Encurtadores: bit.ly, tinyurl, t.co, goo.gl, qualquer encurtador público. O Meta não consegue inspecionar o destino final.
• wa.me/...: links que abrem um chat do WhatsApp. Perde sentido dentro do próprio canal e se associa a esquemas bot-to-bot.
• Domínios off-brand: se a conta é restaurantelagaviota.com.ar e o link vai para tracking-supercheap.io, é rejeitado por mismatch.
• Links para IP direto (http://190.43.x.x/...): inseguro.
• Subdomínios suspeitos: secure-login-banco.com é rejeitado mesmo que tecnicamente exista.

Como consertar:

• Use sempre o domínio oficial da marca, sem encurtadores. Se precisar de métricas de clique, configure um redirect próprio (ex.: tienda.com/r/abc123) — isso é válido.
• O link tem que estar em HTTPS.
• Evite misturar 2-3 domínios distintos em um mesmo modelo.

Razão 6: pedido de dados sensíveis

Por política do Meta e por compliance regional (LGPD no Brasil, Habeas Data na Argentina, leis de proteção de dados no México), um modelo não pode pedir dados sensíveis diretamente. O modelo pode informar — não coletar.

Dados proibidos no corpo de um modelo:

• Número completo de cartão de crédito ou débito.
• Código de segurança (CVV).
• Senhas ou PINs.
• Número completo de conta bancária, CBU, IBAN.
• Documento de identidade completo (DNI, CURP, RFC, RUT) — pedir os últimos 4 dígitos é permitido em algumas verticais.
• Dados médicos sensíveis fora de contexto clínico.

Padrões que são rejeitados automaticamente:

• "Responda esta mensagem com seu CPF completo e data de nascimento."
• "Para confirmar a operação, envie os 16 dígitos do seu cartão."
• "Diga sua senha atual para que possamos ajudar."

Como resolver: o modelo pode levar o usuário a um canal seguro (o app, um link para um formulário próprio em HTTPS, uma ligação com um agente). Nunca pedir o dado dentro do chat.

Razão 7: novas regras rígidas de 2026

Esse grupo reúne as regras que se afiaram nos últimos 12 meses e ainda geram rejeições por desconhecimento.

As que mais vemos rejeitar em contas de clientes:

• Body de Marketing ou Utility >550 caracteres → rejeição automática. A regra anterior tolerava até 1.024. Hoje um modelo de 600 caracteres não entra em revisão, é rejeitado direto.
• Mais de 10 emojis no body → rejeição. Antes o limite era informal; em 2026 é rígido.
• Mais de 4 espaços consecutivos, tabs, linhas em branco múltiplas → rejeição por formato. Se você copiou o texto de um PDF, quase certo que tem caracteres invisíveis.
• Modelos duplicados → qualquer modelo com o mesmo body ou footer que outro modelo aprovado na conta é rejeitado, exceto as AUTHENTICATION. Isso quebra operações que tinham "o mesmo modelo" em templates distintos por estilo.
• Mismatch de idioma: declarar o modelo em es_AR mas escrever o body em português → rejeição TAG_CONTENT_MISMATCH.
• Sample values faltando em modelos com mídia (imagem, vídeo, documento). Sem um sample válido enviado, não há aprovação possível.

Essas regras, exceto as relacionadas a duplicados, não são anunciadas com 30 dias de antecedência. O Meta as aplica com a atualização do API e ficam sabendo as contas que colidem. A política oficial está em developers.facebook.com.

Depois de aprovado, o modelo ainda pode cair

Passar pela aprovação inicial é só metade do trabalho. O Meta avalia cada modelo em produção contra como os usuários o recebem. As métricas relevantes são bloqueios, denúncias como spam, read rate (target saudável: 65-80%) e respostas. Quando a qualidade cai, o modelo passa por uma progressão escalonada:

No nível da conta, se o Quality Rating do número telefônico cair para Low de forma sustentada, o número entra em estado FLAGGED e fica bloqueado para subir de tier de mensagens. Você não consegue escalar para 10K ou 100K mensagens/dia até o rating se recuperar.

A forma de prevenir isso não é escrever um modelo "perfeito", mas monitorar o Quality Rating diariamente, segmentar audiências e arquivar modelos com engajamento baixo antes que sejam punidos. Falamos disso em profundidade em WhatsApp Business API: 9 erros que degradam seu número.

Caso especial: o bloqueio aos Estados Unidos segue ativo

Se sua audiência inclui números dos Estados Unidos, há uma restrição adicional ativa desde 1 de abril de 2025 e segue vigente em abril de 2026 sem data de reativação: o Meta pausou a entrega de modelos MARKETING para números US.

O que ainda passa para os EUA:

• Modelos UTILITY (notificações, alertas, atualizações de status).
• Modelos AUTHENTICATION (OTP, verificação).
• Mensagens dentro da janela de serviço de 24 horas.
• Click-to-WhatsApp Ads (a conversa começa com engajamento explícito).

Se sua campanha mirava os EUA, a opção operacional é reformular o caso de uso como utility honesta ou mover o envio promocional para outros canais. Não há workaround válido; tentar enviar marketing aos EUA mesmo assim gera bloqueios em massa e degrada o número.

Como gerenciamos isso na AsisteClick

Operamos contas WABA o dia todo como parceira Gupshup. Para clientes que querem delegar a gestão, AsisteChat inclui redação de modelos, submissão ao Meta, gestão de apelações e monitoramento diário de Quality Rating. Para campanhas em massa, Wadalio roda o envio com segmentação de audiência e rate limiting interno que respeita seu tier sem que você tenha que pensar.

O que nossa equipe faz concretamente:

• Escreve o modelo na categoria correta antes de enviar, evitando a reclassificação automática.
• Revisa formato (variáveis, links, comprimento, emojis) contra a lista de regras rígidas.
• Monitora o Quality Rating diário e arquiva modelos com engajamento baixo antes que entrem em PAUSED.
• Gerencia apelações quando um modelo legítimo cai por uma decisão arbitrária da revisão humana — e na LATAM isso acontece.

Se quiser experimentar, você pode começar pelo plano Business por USD 20/mês, que inclui integração WABA com bot builder atribuído. Para contas de alto volume que precisam de linguagem generativa, o plano IA Plus soma AsisteGPT y AsisteCopilot na mesma conta.

Perguntas frequentes

Quanto tempo demora a aprovação de um modelo em 2026?

Entre 1 minuto e 48 horas dependendo da complexidade e da fila de revisão do Meta. A maioria dos modelos UTILITY e AUTHENTICATION passa em menos de 5 minutos. Os MARKETING levam entre 30 minutos e 24 horas. Se entrou em revisão humana, assuma 48 horas. Os que são rejeitados automaticamente voltam em segundos.

O que faço se rejeitarem um modelo que considero correto?

Você tem dois caminhos: (1) usar o botão "Request Review" no Meta Business Manager para apelar — funciona quando o Meta classificou errado e o modelo cumpre as regras; (2) reescrever e enviar de novo. Na prática, reescrever é mais rápido. Apelar faz sentido quando você vai enviar centenas de modelos similares e quer estabelecer precedente.

Posso enviar o mesmo modelo em vários idiomas?

Sim, mas como idiomas dentro do mesmo template name, não como modelos separados. Criar um só template com o idioma es_AR para Argentina e pt_BR para Brasil dentro do mesmo nome. Se você fizer dois modelos separados com o mesmo body, o Meta rejeita o segundo como duplicado.

Por que o Meta às vezes aprova um modelo e o pausa no dia seguinte?

Porque a aprovação inicial cobre formato e categoria, não comportamento em produção. Se os primeiros mil envios têm taxa alta de bloqueios ou denúncias, o sistema entra em PAUSED. Acontece com modelos legítimos se a audiência não esperava a mensagem (lista mal segmentada ou sem opt-in claro).

Os modelos AUTHENTICATION têm regras diferentes?

Sim. Os AUTHENTICATION são os únicos que podem ter corpo quase vazio ({{1}} es tu código de verificación), podem ser duplicados entre templates e têm tarifa específica. Em troca, não podem incluir links, não podem personalizar além do código, e só podem ser usados para verificação real — usá-los para promoções é violação de policy.

Trocar de BSP ajuda se eu tiver modelos rejeitados?

Não. Os modelos vivem na conta do Meta Business Manager + número WABA, não no BSP. Trocar de BSP não reseta nem melhora a aprovação. O que muda é a qualidade do suporte na apelação: um BSP com boa relação operacional com o Meta tem tempos de resposta melhores que um sem contato direto.

Continue lendo

• WhatsApp Business API: 9 erros que degradam seu número — o que o Meta faz depois de aprovar o modelo
• Como qualificar leads no WhatsApp com um Agente de IA — segmentação prévia para melhorar o engajamento
• Por que 70% dos leads do WhatsApp são perdidos antes de chegar a um vendedor — o custo real de um modelo mal desenhado
• Chatbot WhatsApp: preços e funcionalidades para empresas 2026 — o pricing per-message do Meta e como calcular o custo total