Erro 131049 no WhatsApp: a mensagem de marketing que a Meta decidiu não entregar

O que a Meta responde quando decide não entregar

A página Error codes da documentação da Cloud API descreve o 131049 numa frase que diz muito pelo que deixa de fora: “This message was not delivered to maintain healthy ecosystem engagement.” Não fala em número inválido, em template reprovado nem em conta restrita. Fala do ecossistema — da caixa de entrada de quem ia receber a mensagem. O erro não avisa que algo quebrou do seu lado. Avisa que a Meta escolheu não entregar.

Ele também não chega onde muita integração procura. A chamada a /messages volta com HTTP 200, um wamid e message_status igual a accepted, como qualquer envio bem-sucedido. A recusa vem depois, no webhook messages: um status failed, com o código dentro de errors[] e a explicação em error_data.details. Quem considera entregue tudo o que a API aceitou conta o 131049 como sucesso — e a campanha mostra uma taxa de entrega que nunca aconteceu.

Um detalhe de implementação que evita retrabalho: compare o code, não o texto. A própria página de códigos de erro avisa que o título que acompanha cada erro vai ser descontinuado e pede que a lógica de tratamento se apoie em code e details. Texto de erro muda de redação sem aviso; o número fica. E o error_subcode, que algumas integrações antigas ainda leem, deixou de vir desde a versão 16.0 da API.

Um limite por pessoa, que soma o marketing de todas as empresas

A causa mais comum do 131049 é o limite de marketing por usuário, descrito na página Per-user marketing template message limits. O WhatsApp pode limitar quantos templates de marketing uma pessoa recebe “from any business in a given period of time” quando ela está menos propensa a se interessar por eles. De qualquer empresa: o teto não é entre você e o seu cliente, é entre o seu cliente e todo mundo que manda marketing para ele.

O critério também não é fixo. Segundo a mesma página, a Meta decide com base em vários fatores, entre eles a taxa de leitura recente de marketing daquela pessoa e quantas mensagens ela tem na caixa de entrada — de amigos, de família e de empresas. O limite se ajusta sozinho ao engajamento: em semanas de pouca leitura ou de caixa cheia, a mesma pessoa recebe menos marketing. A Meta faz questão de dizer que a capacidade de alcançar alguém quando essa pessoa está engajada não muda.

Por isso não existe um número para pôr numa constante. Circulam em blogs de fornecedores regras como “duas mensagens de marketing por dia”, herdadas dos primeiros testes da Meta, em 2024. A documentação atual não publica número nenhum, e um agendador construído em cima de uma cota fixa erra para os dois lados: segura mensagens que seriam entregues e solta as que vão bater no limite.

Duas regras de contagem ajudam a planejar. Conta cada template de marketing entregue — o que falhou não ocupa vaga. E marketing enviado dentro de uma janela de atendimento não conta: quando a pessoa responde a uma mensagem de marketing, abre-se a janela de 24 horas, e o marketing que você mandar dentro dela fica fora do limite. A consequência prática aparece mais adiante, mas a ideia é simples: conversa aberta protege a entrega.

Por que esperar 24 horas, e o que acontece se você não esperar

A orientação da Meta para o 131049 é uma só, e aparece tanto na página de códigos de erro quanto na do limite por usuário: espere pelo menos 24 horas antes de reenviar o template para aquela pessoa. Reenviar antes, diz a documentação, tende a gerar mais erros e a reduzir a precisão dos relatórios de entrega da campanha.

Há uma segunda regra, menos conhecida, que transforma o retry apressado em prejuízo. A Meta limita tentativas excessivas: se a conta reenvia marketing várias vezes, dentro de 24 horas, para quem já bateu o limite, novas tentativas para essas pessoas podem ficar indisponíveis por até 24 horas — com o mesmo 131049. A punição é por destinatário e não afeta o envio para os demais, mas o efeito sobre aquele cliente é concreto: o retry que pretendia acelerar a entrega a empurra para mais longe.

Vimos o padrão acontecer. Um atendente mandou um template de marketing pelo inbox, recebeu o 131049 cerca de um segundo depois e, achando que era instabilidade, clicou em reenviar. A segunda tentativa falhou do mesmo jeito. Desde então, a mesma regra vale nas duas pontas do nosso produto — o reenvio da conversa e o reprocessamento de falhas da campanha: o 131049 só volta para a fila 24 horas depois da falha, e o composer avisa antes de mandar marketing para quem a Meta recusou nesse intervalo.

Vinte e quatro horas a partir de quê? A documentação manda esperar antes de reenviar, mas não define o relógio. A nossa leitura, que é recomendação e não regra da Meta: conte a partir do failed, que é o instante em que você soube da recusa, e não da criação da mensagem. Numa campanha agendada para a madrugada e processada em lotes, a diferença entre os dois relógios pode ser de horas — e é justamente a diferença que gera o segundo 131049.

Uma campanha, quatro falhas diferentes

O 131049 raramente aparece sozinho. Numa campanha de um cliente que analisamos, o painel mostrava 68 falhas, e o pedido foi um relatório do que tinha acontecido. Medido no banco, eram quatro coisas diferentes: 56 vezes o 131026, seis vezes o 131049, cinco vezes o 130472 e uma vez o código 100. Quatro causas, quatro respostas — e duas delas opostas ao que a tela sugeria.

O 131026 é o caso do número que não pode receber: não tem WhatsApp, não aceitou os termos de uso ou está com o aplicativo desatualizado demais. Reenviar para o mesmo número não muda nada; o que resolve é confirmar o número com a pessoa, por outro canal. No Brasil, parte desses casos é o nono dígito — celular cadastrado no formato antigo, sem o 9 na frente —, e vale conferir isso antes de concluir que o cliente não usa WhatsApp.

O 130472 é um experimento da Meta, descrito na página Experiments: uma porcentagem muito pequena de usuários não recebe marketing de nenhuma empresa, a menos que exista uma janela de atendimento aberta com quem envia. A Meta não cobra a mensagem, e reenviar dá o mesmo erro. Não há prazo para o experimento acabar nem forma de tirar alguém dele; a saída que a documentação oferece é pedir, por outro canal, que a pessoa escreva para você, e mandar a mensagem com a janela aberta.

O 131050 é decisão do cliente: ele usou a opção de parar de receber marketing da sua empresa. A orientação é não reenviar, porque a mensagem não será recebida, e assinar o webhook user_preferences, que avisa quando alguém para ou volta a aceitar marketing. O 100, por fim, é parâmetro recusado — um dado errado no template, que só se corrige no conteúdo. Tratar os quatro como “falha” faz o operador reenviar o que não vai sair e desistir do que sairia no dia seguinte.

Estados Unidos: o 131049 que esperar não resolve

Existe um 131049 que não tem nada a ver com engajamento. Desde 1º de abril de 2025, a Meta não entrega templates de marketing para pessoas com número dos Estados Unidos — o código +1 com um DDD americano —, e a página Get started da Marketing Messages API diz qual erro sai: o 131049. A restrição vale em todas as APIs de mensagens da Meta, inclusive a Cloud API, e a página do limite por usuário ainda a descreve no presente. Não há data anunciada para a volta.

Nesse caso, esperar 24 horas é inútil. O motivo é estrutural, não de saturação, e o reenvio volta com o mesmo código até que a Meta mude a regra. Por isso o tratamento do 131049 precisa olhar o destinatário antes de olhar o relógio: mesmo código, duas causas, duas respostas. Para número americano, a mensagem de marketing não deve nem entrar na fila de reenvio — e, melhor ainda, não deve sair na campanha.

A restrição é sobre marketing. Utility e autenticação continuam sendo entregues para números dos Estados Unidos, o que importa para a empresa brasileira que vende para fora: confirmação de pedido, aviso de entrega e código de verificação seguem funcionando. O que não passa é promoção — e um template de promoção registrado como utility não resolve, porque a Meta confere a categoria pelo conteúdo e reclassifica o que estiver errado. Um utility que vira marketing passa a seguir as regras do marketing, inclusive esta.

Onde o limite não vale, e como a janela protege a entrega

O limite por usuário não está ativo em todos os mercados. Segundo a página Get started da Marketing Messages API, ele não vale no Espaço Econômico Europeu, no Reino Unido, no Japão, na Coreia do Sul, na Nigéria, na África do Sul e na Tailândia — a Tailândia entrou na lista em setembro de 2026. O Brasil não está entre as exceções: para quem envia para números brasileiros, o 131049 faz parte da operação.

A regra de contagem é a melhor ferramenta que a Meta deixa na mão de quem envia. Marketing dentro de uma janela de atendimento não conta no limite, e a janela abre quando a pessoa escreve para você — inclusive respondendo a uma mensagem de marketing. Um template com botão de resposta rápida que o cliente toca abre a janela; a oferta que você mandar nas 24 horas seguintes não disputa vaga com as mensagens das outras empresas.

Isso muda o desenho de uma campanha. Em vez de dois disparos frios para a mesma base em dias seguidos, um primeiro contato que convida resposta e uma continuação, dentro da janela, para quem respondeu. Anúncio de clique para o WhatsApp funciona pela mesma lógica: quem chega pela conversa já abriu a janela. Não é truque. É a regra escrita pela Meta premiando quem conversa em vez de só disparar.

Vale a ressalva: a janela não muda a categoria. A mensagem continua sendo marketing e continua sendo cobrada como marketing, com a janela aberta ou fechada. O que a janela muda é só a contagem do limite por usuário e, com ela, a chance de o 131049 aparecer. E ela não dura para sempre: 24 horas depois da última mensagem do cliente, a próxima oferta volta a disputar vaga.

O que acontece antes do 131049: preferência, qualidade e ritmo

O limite por usuário não é o único filtro entre o seu template e a caixa de entrada. A página Marketing templates descreve uma configuração do próprio WhatsApp, chamada Offers and announcements, em que a pessoa diz se tem interesse no marketing da sua empresa. Quem marca que não tem interesse pode afetar o limite por usuário entre você e ela — é a parte do limite que depende só de você — e logo em seguida vê a opção de parar de receber o seu marketing. Interesse e desinteresse não disparam webhook; só parar e voltar disparam o user_preferences.

Depois vem a qualidade do template. Cada template tem uma classificação no campo quality_score — GREEN, YELLOW, RED ou UNKNOWN —, calculada a partir de uso, feedback e engajamento, como bloqueios, denúncias e leitura baixa. Segundo a página Template pausing, um template que chega ao vermelho é pausado por três horas na primeira vez, por seis na segunda, e desativado na terceira. Envio com template pausado falha com o 132015 e não é cobrado; com template desativado, o código é o 132016.

E há o ritmo. A página Template pacing descreve quando a Meta segura uma parte das mensagens de um template para medir a reação antes de liberar o resto: a resposta do envio vem com message_status igual a held_for_quality_assessment no lugar de accepted, e, se o feedback inicial for ruim, as mensagens retidas caem com o 132015. Um template ruim não espera o 131049 para ser contido.

Por fim, não confunda o 131049 com o 131048. O 131049 é sobre quem recebe; o 131048 é sobre quem envia — restrição de envio porque mensagens anteriores do número foram bloqueadas ou marcadas como spam. O primeiro se resolve com espera e relevância; o segundo pede olhar a qualidade do número no Gerenciador do WhatsApp antes de mandar qualquer outra coisa. E a Meta é explícita numa diferença que surpreende: na Cloud API, “Message quality does not factor into per-user marketing message limits”. Template bom não abre exceção no limite por usuário; ele só passa pelos outros filtros.

Como medir o efeito numa campanha

O 131049 precisa virar métrica, e a Meta não entrega essa métrica pronta. A página Analytics lista os campos analytics, pricing_analytics e template_analytics da conta, e nenhum deles separa falhas por código: o pricing_analytics conta só mensagens entregues, e o template_analytics traz enviadas, entregues, lidas e clicadas. A diferença entre enviadas e entregues mistura 131049, 130472, 131026 e tudo o mais. A fonte do número certo é o seu próprio registro de webhooks.

O registro mínimo, na nossa experiência, tem quatro campos por falha: o wamid, o código, o instante do failed e a campanha ou o envio de origem. Com eles dá para calcular, por campanha e por segmento, a parcela de destinatários que voltou com 131049 — e acompanhar se ela sobe. Uma taxa que cresce de campanha para campanha na mesma base é sinal de saturação: a mesma lista recebendo marketing demais, seu e dos outros.

Compare segmentos pelo que o limite mede. Se o critério da Meta é engajamento recente, quem leu, clicou ou respondeu nas últimas semanas tende a receber, e quem ignora tudo há meses tende a bater no limite. Separar a base por recência de interação e olhar o 131049 em cada fatia transforma um erro opaco num indicador de qualidade da lista — e mostra onde vale mandar menos, ou mandar outra coisa.

Sobre custo, a regra da página Pricing é que a empresa só paga mensagem entregue, e a referência do webhook de status mostra o objeto pricing acompanhando sent, delivered e read, não o failed. O 131049 não aparece na fatura da Meta. Aparece em outro lugar: cada recusa é uma pessoa da campanha que não viu a oferta — e, com retry apressado, uma pessoa que não vai ver nem amanhã.

A Marketing Messages API, e o fim do marketing na Cloud API

A Meta tem uma API separada para marketing, a Marketing Messages API for WhatsApp, que começou como MM Lite e saiu do beta em 19 de novembro de 2025, já com o nome novo. A diferença que interessa aqui está na página Features: ela leva em conta se a mensagem é de alto engajamento na decisão de entregar, e a Meta fala em “up to 9% more messages” entregues em relação à Cloud API, onde a qualidade da mensagem não entra no limite por usuário.

O número tem contexto, e a própria Meta o dá numa nota de rodapé: um teste A/B com cerca de 12 milhões de mensagens de anunciantes na Índia, em janeiro de 2025, comparando só mensagens de alto engajamento. Ou seja, a API nova não elimina o 131049. Os códigos de erro são os mesmos, e a restrição para números dos Estados Unidos vale nela também. Ela melhora a entrega do que já é relevante; não salva o que não é.

A notícia maior saiu em 13 de outubro de 2026, na página Overview da mesma API: a Cloud API vai deixar de aceitar marketing. Contas de mensagens criadas a partir de 13 de abril de 2027 já não conseguem mandar marketing pela Cloud API; as criadas antes seguem até 13 de outubro de 2027, quando o envio de marketing pela Cloud API passa a dar erro. Utility, autenticação e atendimento continuam na Cloud API como estão.

Para quem integra, isso é migração com prazo — a Meta estima cerca de duas semanas para a maioria das integrações. O marketing passa a sair por POST /<PHONE_NUMBER_ID>/marketing_messages, que aceita só templates de marketing, com product_policy em CLOUD_API_FALLBACK ou STRICT. E a Meta pede atenção ao tráfego reclassificado: utility que ela recategorizou como marketing precisa ir pela API nova, então a integração tem de saber a categoria atual de cada template, e o webhook template_category_update existe para isso. Quem deixar para outubro de 2027 vai descobrir o prazo pelo erro.