131047, 131051 e 133010: o que a Cloud API quer dizer quando recusa a sua mensagem
Três códigos que aparecem cedo em qualquer integração com o WhatsApp e cujos nomes na documentação apontam para o lugar errado. Um deles culpa o destinatário quando o problema é o remetente.
Engenharia CCXPlataforma · Engenharia · 22 ago 2026 · 8 min de leitura
O que você leva
- Como distinguir os dois erros de janela — e por que só um deles é culpa sua
- Por que 133010 quase nunca é sobre a conta que você está olhando
- O comando de diagnóstico que resolve o caso em um minuto em vez de uma tarde
131047 — reengajamento fora da janela
Significa que você tentou enviar mensagem de formato livre depois de a janela de 24 horas ter fechado. É o erro mais comum da lista e o mais fácil de entender: fora da janela, só template aprovado.
O que confunde é quando ele aparece com a janela aparentemente aberta. Nesse caso o problema quase nunca é a regra — é o cálculo dela. Se você ancorou a janela no horário em que processou o webhook em vez do timestamp que veio dentro dele, qualquer reentrega atrasada da Meta infla a sua janela e o 131047 vira um mistério. Escrevemos sobre esse detalhe em um post inteiro, porque ele sozinho explica a maioria dos casos.
131051 — o tipo que a Cloud API não representa
Este não é um erro de envio: ele chega no evento de RECEBIMENTO. Aparece quando o cliente manda algo que a Cloud API não consegue entregar para você em formato estruturado, e a mensagem chega com o tipo unsupported.
A armadilha é tratá-lo como uma mensagem qualquer. Ele não abre a janela de atendimento. Se o seu código registra a janela em cima dele, você fica com uma conversa que o seu sistema julga aberta e a Meta julga fechada — e o próximo envio livre volta como 131047. Os dois erros são o mesmo bug visto de dois ângulos.
O tratamento correto é registrar a mensagem no histórico para o atendente saber que algo chegou, sem abrir janela, sem disparar automação e sem acionar IA.
133010 — o erro cujo nome mente
A mensagem da Meta é “Account not registered”, o que soa como problema da conta do destinatário. Não é. Significa que o phone_number_id usado para enviar aquela conversa específica não está registrado na Cloud API.
O detalhe que consome tardes inteiras: não é necessariamente o número que você está vendo na tela. Uma organização pode ter dois registros do mesmo telefone — um ativo e um resíduo de migração, marcado como desconectado. Conversas importadas ficam amarradas ao registro velho. Resultado: o mesmo template entrega numa conversa e falha na outra, no mesmo minuto, com todos os indicadores da interface verdes.
Piora porque a maioria das telas de números esconde os registros desconectados. O remetente culpado fica invisível exatamente na interface onde você foi procurar.
O diagnóstico que corta o caminho
Antes de investigar token, tier, saldo ou registro, compare o phone_number_id de uma mensagem que falhou com o de uma que passou. Se forem diferentes, você tem registro fantasma e o resto da investigação é perda de tempo. Se forem iguais, aí sim vale olhar registro e token.
Vale lembrar de dois detalhes que enganam durante essa checagem: o selo “conectado” da sua lista de números costuma ser campo do seu próprio banco, não uma consulta à Meta; e endpoints de saúde às vezes caem em modo local silencioso quando a Meta falha, devolvendo verde sem ter perguntado a ninguém.