131047, 131051 y 133010: qué quiere decir la Cloud API cuando rechaza tu mensaje
Tres códigos que aparecen pronto en cualquier integración con WhatsApp y cuyos nombres en la documentación apuntan al lugar equivocado. Uno de ellos culpa al destinatario cuando el problema es el remitente.
Ingeniería CCXPlataforma · Ingeniería · 22 ago 2026 · 8 min de lectura
Lo que te llevas
- Cómo distinguir los dos errores de ventana — y por qué solo uno es culpa tuya
- Por qué 133010 casi nunca trata de la cuenta que estás mirando
- El diagnóstico que cierra el caso en un minuto en vez de una tarde
131047 — reenganche fuera de la ventana
Significa que intentaste enviar un mensaje de formato libre después de que la ventana de 24 horas se cerrara. Es el error más común de la lista y el más fácil de entender: fuera de la ventana, solo plantillas aprobadas.
Lo que confunde es verlo con la ventana aparentemente abierta. En ese caso el problema casi nunca es la regla, sino tu cálculo. Si anclaste la ventana a la hora en que procesaste el webhook en vez del timestamp que venía dentro, cualquier reentrega tardía de Meta infla tu ventana y el 131047 se vuelve un misterio. Le dedicamos un post entero a ese detalle, porque él solo explica la mayoría de los casos.
131051 — el tipo que la Cloud API no representa
Este no es un error de envío: llega en el evento de RECEPCIÓN. Aparece cuando el cliente manda algo que la Cloud API no puede entregarte en formato estructurado, y el mensaje llega con el tipo unsupported.
La trampa es tratarlo como un mensaje cualquiera. No abre la ventana de atención. Si tu código registra la ventana a partir de él, te quedas con una conversación que tu sistema cree abierta y Meta cree cerrada — y el siguiente envío libre vuelve como 131047. Los dos errores son el mismo bug visto desde dos ángulos.
El tratamiento correcto es registrar el mensaje en el historial para que el agente sepa que llegó algo, sin abrir ventana, sin disparar automatización y sin activar la IA.
133010 — el error cuyo nombre miente
El mensaje de Meta es “Account not registered”, que suena a problema de la cuenta del destinatario. No lo es. Significa que el phone_number_id usado para enviar esa conversación concreta no está registrado en la Cloud API.
El detalle que se come tardes enteras: no es necesariamente el número que estás viendo en pantalla. Una organización puede tener dos registros del mismo teléfono — uno activo y otro residuo de migración, marcado como desconectado. Las conversaciones importadas quedan atadas al registro viejo. Resultado: la misma plantilla entrega en una conversación y falla en otra, en el mismo minuto, con todos los indicadores de la interfaz en verde.
Empeora porque la mayoría de las pantallas de números esconde los registros desconectados. El remitente culpable queda invisible justo en la interfaz donde fuiste a buscar.
El diagnóstico que acorta el camino
Antes de investigar token, tier, saldo o registro, compara el phone_number_id de un mensaje que falló con el de uno que pasó. Si son distintos, tienes un registro fantasma y el resto de la investigación es tiempo perdido. Si coinciden, entonces sí vale mirar registro y token.
Dos cosas engañan durante esa comprobación: el sello “conectado” de tu lista de números suele ser un campo de tu propia base de datos, no una consulta a Meta; y los endpoints de salud a veces caen en un modo local silencioso cuando Meta falla, devolviendo verde sin haber preguntado a nadie.