Por que a Meta rejeita seu template (e como aprovar de primeira)
Os motivos reais por que a Meta rejeita templates do WhatsApp (category mismatch, placeholder solto, formatação spam) e o checklist de QA para aprovar de primeira.
Você submete um template, espera, e volta REJECTED.
Sem explicação. Sem log útil. Só o status e, se tiver sorte, um reason genérico no webhook.
Isso trava onboarding, atrasa campanha e queima tempo de engenharia em algo que deveria ser trivial.
Mas a parte que enlouquece não é a rejeição. É o silêncio. Sem detalhe no reason, o instinto é reenviar o mesmo template com um emoji a menos e torcer. Aí você queima mais um ciclo de revisão para aprender exatamente nada.
Só que rejeição quase nunca é azar.
A Meta revisa cada template (em geral em minutos, às vezes mais). E a maioria das reprovações cai em três ou quatro padrões previsíveis. Categoria errada e variável mal preenchida lideram com folga.
Quando você entende o que o revisor procura, dá para aprovar de primeira de forma consistente. Este guia mapeia os motivos reais e fecha com um checklist de QA.
O que acontece na revisão
Todo template passa por um estado: PENDING → APPROVED ou REJECTED. A revisão combina checagem automática e, em alguns casos, revisão humana. O resultado chega no webhook message_template_status_update, com um campo reason quando reprova.
O ponto que pega quase todo mundo é este: a revisão não olha só se tem palavrão.
Ela avalia se a categoria declarada bate com o conteúdo, se os placeholders fazem sentido, e se a mensagem parece confiável para quem recebe. É filtro de qualidade e de política ao mesmo tempo.
Os motivos que mais reprovam
1. Category mismatch
O erro número um. Você escreve uma promoção (“20% OFF essa semana!”) e submete como UTILITY, porque utilidade é mais barata. A Meta detecta o conteúdo de marketing e rejeita ou recategoriza. Se recategorizar, você paga preço de marketing achando que paga utilidade.
Regra prática: MARKETING para promoção e reengajamento. UTILITY para transacional (confirmação de pedido, atualização de status, lembrete de cobrança). AUTHENTICATION só para OTP.
O teste é simples. A mensagem existe por causa de uma ação que o usuário tomou (comprou, agendou, pediu código)? É utility. Existe porque você quer vender algo? É marketing.
(A categoria também muda o custo dentro e fora da janela de 24 horas.)
2. Variáveis e placeholders
Tudo isso reprova por formato: 1 sem sample, variável solta no começo ou no fim do body, duas variáveis coladas (1 2 sem texto no meio), ou número de samples diferente do número de variáveis.
O revisor precisa entender o que cada placeholder representa. Um body que começa com 1, ... sem contexto parece genérico demais.
Coloque texto fixo antes da primeira variável. E preencha valores de exemplo realistas ao submeter.
3. Formatação que parece spam
Excesso de emoji. CAIXA ALTA. URL quebrada ou com placeholder no domínio. Caractere especial demais. Erro de gramática.
Tudo isso baixa o sinal de confiança da mensagem. CLIQUE AQUI!!! é quase um gatilho de rejeição sozinho.
4. Violação de política
Conteúdo proibido ou enganoso. Urgência falsa (“ÚLTIMA CHANCE: sua conta será bloqueada”). Pedido de dado sensível por link. Uso de marca de terceiro ou imitação de mensagem do próprio WhatsApp.
Isso cai como SCAM ou ABUSIVE_CONTENT.
5. Conteúdo vago demais
Clique aqui, frases incompletas, mensagem sem deixar claro quem manda e por quê. Se o destinatário não entende o contexto, o revisor também não.
Tabela: motivo da rejeição → como corrigir
| Motivo da rejeição | Como corrigir |
|---|---|
| Category mismatch (marketing como utility/auth) | Recategorize pelo objetivo real: promoção → marketing; transacional → utility; OTP → authentication. |
| Placeholder ambíguo / sem sample | Dê nome/contexto a cada ``, nunca comece ou termine o body com variável, e preencha samples realistas. |
| Variáveis adjacentes ou contagem errada | Separe variáveis com texto fixo; garanta um sample por variável. |
| Formatação spam (CAIXA ALTA, emoji em excesso, “CLIQUE AQUI!!!”) | Tom neutro, pontuação normal, no máximo 1–2 emojis, gramática revisada. |
| URL inválida / placeholder no domínio | Use uma URL real e acessível; nada de https://seudominio.com. |
| Violação de política (golpe, urgência falsa, marca de terceiros) | Remova urgência artificial e pedido de dados sensíveis; não imite mensagens da Meta/WhatsApp. |
| Conteúdo vago (“clique aqui”, frase incompleta) | Deixe explícito quem envia, por quê, e o que a pessoa deve fazer. |
| Nome do template inválido | Apenas minúsculas, números e underscore (ex.: pedido_confirmado_v2). |
Antes e depois de um template
Veja um template que será rejeitado: marketing disfarçado de utility, placeholder solto e formatação de spam:
Categoria: UTILITY
Header: 🔥🔥 OFERTA IMPERDÍVEL 🔥🔥
Body: 1 CLIQUE AQUI AGORA!!! Só hoje você ganha
desconto. Acesse https://seusite.com/promo
Problemas: é promoção marcada como utility (category mismatch), o body começa com 1 sem contexto, tem CAIXA ALTA, emoji em excesso, URL com domínio-placeholder e zero opt-in.
Agora a versão corrigida, como utility legítima (uma confirmação real), com samples preenchidos:
Categoria: UTILITY
Header: Pedido confirmado
Body: Olá 1, seu pedido 2 foi confirmado e já
está em separação. Você pode acompanhar o status pelo
botão abaixo.
Sample: 1 = "Ana", 2 = "#10482"
Botão: URL → "Acompanhar pedido"
Texto antes da variável, contexto claro, categoria honesta, URL válida no botão. Esse passa.
Leia a mensagem como se você fosse quem recebe. Se dá para entender quem manda, por que manda e o que fazer, sem gritaria nem urgência fabricada, ela quase sempre passa. Categoria honesta já resolve metade.
Templates aprovados também podem ser pausados
Aprovar não é para sempre.
Um template aprovado, mas ruim na prática, pode ser pausado ou desabilitado se os usuários reagirem mal: bloqueio, denúncia de spam, baixa leitura. O status vira PAUSED e o template para de enviar até a qualidade melhorar.
Isso conecta direto ao quality rating do seu número. Template ruim derruba o rating. Rating ruim pausa template e estreita o seu limite de envio.
Monitorar o webhook de status e medir engajamento por template não é luxo. É o que evita descobrir o problema tarde demais.
Checklist de QA antes de submeter
Antes de mandar qualquer template para revisão:
- Categoria honesta: promoção é marketing, ponto. Não tente economizar disfarçando.
- Samples preenchidos com valores realistas, um por variável.
- Sem variável no começo/fim do body e sem variáveis adjacentes.
- URLs reais e acessíveis (nada de
seudominio.com). - Tom neutro: sem CAIXA ALTA, sem
!!!, no máximo 1–2 emojis. - Gramática revisada: erro de português baixa o sinal de confiança.
- Nome válido: minúsculas, números, underscore.
- Opt-in coerente: se é marketing, a pessoa optou por receber? Inclua opção de sair.
- Reuse padrões aprovados: se um template já passou, parta dele em vez de inventar do zero.
Esse último ponto vale ouro para quem opera em escala. Padronize um punhado de templates por categoria que você sabe que passam. E versione (_v2, _v3) em vez de recriar do zero.
Perguntas frequentes
Quanto tempo leva a revisão de um template? Em geral minutos, mas pode levar mais quando entra revisão humana. Não há SLA garantido: planeje submeter com antecedência, não na véspera da campanha.
A Meta diz exatamente por que rejeitou?
Nem sempre. Você recebe um reason no webhook (INCORRECT_CATEGORY, INVALID_FORMAT, SCAM, ABUSIVE_CONTENT ou NONE), mas o detalhamento costuma ser raso. Quando vier NONE, revise o template inteiro: contexto, tom, variáveis e opt-in.
Posso editar um template já aprovado em vez de criar outro? Sim, a Meta permite editar templates aprovados; a edição vai para nova revisão e, enquanto isso, a versão anterior continua valendo. Verifique as regras atuais de edição na documentação oficial, porque mudam.
Por que o de Authentication aprova quase sempre? Porque segue um formato padrão da Meta (OTP). Quanto menos você customiza, mais rápido passa. Não tente “enfeitar” um template de código de verificação.
As diretrizes de template e os motivos de rejeição mudam com frequência. Valide sempre na fonte oficial: diretrizes de message templates da Meta e nas políticas vigentes. Conteúdo da comunidade WhatsApp Founders 🇧🇷. Independente, sem vínculo oficial com o WhatsApp ou a Meta.