Error 131049 en WhatsApp: el mensaje de marketing que Meta decidió no entregar

Qué responde Meta cuando decide no entregar

La página Error codes de la documentación de la Cloud API describe el 131049 en una frase que dice mucho por lo que deja fuera: “This message was not delivered to maintain healthy ecosystem engagement.” No habla de número inválido, de plantilla rechazada ni de cuenta restringida. Habla del ecosistema — de la bandeja de entrada de quien iba a recibir el mensaje. El error no avisa de que algo se ha roto en tu lado. Avisa de que Meta eligió no entregar.

Tampoco llega donde muchas integraciones lo buscan. La llamada a /messages vuelve con HTTP 200, un wamid y message_status igual a accepted, como cualquier envío correcto. El rechazo llega después, en el webhook messages: un estado failed, con el código dentro de errors[] y la explicación en error_data.details. Quien da por entregado todo lo que la API aceptó cuenta el 131049 como éxito — y la campaña muestra una tasa de entrega que nunca existió.

Un detalle de implementación que ahorra trabajo: compara el code, no el texto. La propia página de códigos de error avisa de que el título que acompaña a cada error va a quedar obsoleto y pide que la lógica de tratamiento se apoye en code y details. El texto de un error cambia de redacción sin aviso; el número se queda. Y el error_subcode, que algunas integraciones antiguas todavía leen, no se devuelve desde la versión 16.0 de la API.

Un límite por persona, que suma el marketing de todas las empresas

La causa más habitual del 131049 es el límite de marketing por usuario, descrito en la página Per-user marketing template message limits. WhatsApp puede limitar cuántas plantillas de marketing recibe una persona “from any business in a given period of time” cuando es menos probable que le interesen. De cualquier empresa: el techo no está entre tú y tu cliente, está entre tu cliente y todos los que le envían marketing.

El criterio tampoco es fijo. Según la misma página, Meta decide a partir de varios factores, entre ellos la tasa de lectura reciente de marketing de esa persona y cuántos mensajes tiene en la bandeja de entrada — de amigos, de familia y de empresas. El límite se ajusta solo al engagement: en semanas de poca lectura o de bandeja llena, la misma persona recibe menos marketing. Meta insiste en que tu capacidad de llegar a alguien cuando está más comprometido no cambia.

Por eso no hay un número que poner en una constante. En blogs de proveedores circulan reglas como “dos mensajes de marketing al día”, heredadas de las primeras pruebas de Meta, en 2024. La documentación actual no publica ningún número, y un programador de envíos construido sobre una cuota fija se equivoca en las dos direcciones: retiene mensajes que se habrían entregado y suelta los que van a chocar con el límite.

Dos reglas de cómputo ayudan a planificar. Cuenta cada plantilla de marketing entregada — la que falló no ocupa plaza. Y el marketing enviado dentro de una ventana de atención no cuenta: cuando la persona responde a un mensaje de marketing, se abre la ventana de 24 horas, y el marketing que envíes dentro queda fuera del límite. La consecuencia práctica viene más abajo, pero la idea es sencilla: una conversación abierta protege la entrega.

Por qué esperar 24 horas, y qué pasa si no esperas

La indicación de Meta para el 131049 es una sola, y aparece tanto en la página de códigos de error como en la del límite por usuario: espera al menos 24 horas antes de reenviar la plantilla a esa persona. Reenviar antes, dice la documentación, tiende a generar más errores y a reducir la precisión de los informes de entrega de la campaña.

Hay una segunda regla, menos conocida, que convierte el reintento apresurado en un perjuicio. Meta limita los intentos excesivos: si la cuenta reenvía marketing varias veces, dentro de 24 horas, a quien ya alcanzó su límite, los nuevos intentos a esas personas pueden quedar bloqueados hasta 24 horas — con el mismo 131049. La penalización es por destinatario y no afecta al envío a los demás, pero el efecto sobre ese cliente es real: el reintento que pretendía acelerar la entrega la aleja todavía más.

Hemos visto el patrón. Un agente envió una plantilla de marketing desde el inbox, recibió el 131049 alrededor de un segundo después y, pensando que era un fallo puntual, pulsó reenviar. El segundo intento falló igual. Desde entonces, la misma regla vale en los dos extremos de nuestro producto — el reenvío desde la conversación y el reprocesamiento de fallos de la campaña: el 131049 solo vuelve a la cola 24 horas después del fallo, y el compositor avisa antes de enviar marketing a quien Meta rechazó en ese intervalo.

¿Veinticuatro horas desde cuándo? La documentación manda esperar antes de reenviar, pero no define el reloj. Nuestra lectura, que es recomendación y no regla de Meta: cuenta desde el failed, el momento en que supiste del rechazo, y no desde la creación del mensaje. En una campaña programada de madrugada y procesada por lotes, la diferencia entre los dos relojes puede ser de horas — y es justo esa diferencia la que genera el segundo 131049.

Una campaña, cuatro fallos distintos

El 131049 casi nunca aparece solo. En una campaña de un cliente que analizamos, el panel mostraba 68 fallos, y lo que se pidió fue un informe de lo que había pasado. Medido en la base de datos, eran cuatro cosas distintas: 56 veces el 131026, seis veces el 131049, cinco veces el 130472 y una vez el código 100. Cuatro causas, cuatro respuestas — y dos de ellas contrarias a lo que sugería la pantalla.

El 131026 es el caso del número que no puede recibir: no tiene WhatsApp, no aceptó las condiciones de uso o tiene una versión de la app demasiado antigua. Reenviar al mismo número no cambia nada; lo que lo resuelve es confirmar el número con la persona por otro canal. Antes de concluir que el cliente no usa WhatsApp, conviene revisar el formato: prefijo de país, dígitos de más o de menos, o un número de móvil guardado en un formato antiguo.

El 130472 es un experimento de Meta, descrito en la página Experiments: un porcentaje muy pequeño de usuarios no recibe marketing de ninguna empresa, salvo que exista una ventana de atención abierta con quien envía. Meta no cobra el mensaje, y reenviar da el mismo error. No hay fecha de fin para el experimento ni forma de sacar a alguien de él; la salida que ofrece la documentación es pedir, por otro canal, que la persona te escriba, y enviar el mensaje con la ventana abierta.

El 131050 es decisión del cliente: usó la opción de dejar de recibir marketing de tu empresa. La indicación es no reenviar, porque el mensaje no se recibirá, y suscribirse al webhook user_preferences, que avisa cuando alguien deja de aceptar marketing o vuelve a aceptarlo. Por último, el 100 es un parámetro rechazado — un dato erróneo en la plantilla, que solo se corrige en el contenido. Tratar los cuatro como “fallo” hace que el operador reenvíe lo que no va a salir y abandone lo que saldría al día siguiente.

Estados Unidos: el 131049 que esperar no resuelve

Existe un 131049 que no tiene nada que ver con el engagement. Desde el 1 de abril de 2025, Meta no entrega plantillas de marketing a personas con número de Estados Unidos — el prefijo +1 con un código de área estadounidense —, y la página Get started de la Marketing Messages API dice qué error sale: el 131049. La restricción vale en todas las API de mensajería de Meta, incluida la Cloud API, y la página del límite por usuario todavía la describe en presente. No hay fecha anunciada para que termine.

En este caso, esperar 24 horas es inútil. El motivo es estructural, no de saturación, y el reenvío vuelve con el mismo código hasta que Meta cambie la regla. Por eso el tratamiento del 131049 tiene que mirar el destinatario antes que el reloj: mismo código, dos causas, dos respuestas. Para un número estadounidense, el mensaje de marketing no debería ni entrar en la cola de reenvío — y, mejor aún, no debería salir en la campaña.

La restricción es sobre marketing. Utility y autenticación se siguen entregando a números de Estados Unidos, lo que importa a la empresa que vende fuera: confirmación de pedido, aviso de entrega y código de verificación siguen funcionando. Lo que no pasa es la promoción — y una plantilla promocional registrada como utility no lo resuelve, porque Meta comprueba la categoría a partir del contenido y reclasifica lo que esté mal. Una plantilla utility que pasa a marketing empieza a seguir las reglas del marketing, también esta.

Dónde no vale el límite, y cómo la ventana protege la entrega

El límite por usuario no está activo en todos los mercados. Según la página Get started de la Marketing Messages API, no vale en el Espacio Económico Europeo, en el Reino Unido, en Japón, en Corea del Sur, en Nigeria, en Sudáfrica ni en Tailandia — Tailandia entró en la lista en septiembre de 2026. España forma parte del EEE, así que para números españoles el límite no está activo; México, Colombia, Argentina y el resto de América Latina no están entre las excepciones, y quien envía allí convive con el 131049.

La regla de cómputo es la mejor herramienta que Meta deja en manos de quien envía. El marketing dentro de una ventana de atención no cuenta para el límite, y la ventana se abre cuando la persona te escribe — también respondiendo a un mensaje de marketing. Una plantilla con botón de respuesta rápida que el cliente pulsa abre la ventana; la oferta que envíes en las 24 horas siguientes no compite por plaza con los mensajes de las demás empresas.

Eso cambia el diseño de una campaña. En lugar de dos envíos en frío a la misma base en días seguidos, un primer contacto que invite a responder y una continuación, dentro de la ventana, para quien respondió. Los anuncios que hacen clic a WhatsApp funcionan con la misma lógica: quien llega por la conversación ya abrió la ventana. No es un truco. Es la regla escrita por Meta premiando a quien conversa en lugar de solo enviar en masa.

Una salvedad: la ventana no cambia la categoría. El mensaje sigue siendo marketing y se sigue cobrando como marketing, con la ventana abierta o cerrada. Lo que cambia la ventana es solo el cómputo del límite por usuario y, con él, la probabilidad de que aparezca el 131049. Y no dura para siempre: 24 horas después del último mensaje del cliente, la siguiente oferta vuelve a competir por plaza.

Lo que pasa antes del 131049: preferencia, calidad y ritmo

El límite por usuario no es el único filtro entre tu plantilla y la bandeja de entrada. La página Marketing templates describe un ajuste del propio WhatsApp, llamado Offers and announcements, en el que la persona indica si le interesa el marketing de tu empresa. Marcar que no le interesa puede afectar al límite por usuario entre tú y esa persona — la parte del límite que depende solo de ti — y a continuación le ofrece dejar de recibir tu marketing. Interés y desinterés no disparan webhook; solo dejar de recibir y volver a recibir disparan user_preferences.

Después viene la calidad de la plantilla. Cada plantilla tiene una calificación en el campo quality_score — GREEN, YELLOW, RED o UNKNOWN —, calculada a partir de uso, feedback y engagement, como bloqueos, denuncias y lectura baja. Según la página Template pausing, una plantilla que llega al rojo se pausa tres horas la primera vez, seis la segunda, y se desactiva la tercera. Un envío con plantilla pausada falla con el 132015 y no se cobra; con plantilla desactivada, el código es el 132016.

Y está el ritmo. La página Template pacing describe cuándo Meta retiene una parte de los mensajes de una plantilla para medir la reacción antes de liberar el resto: la respuesta del envío llega con message_status igual a held_for_quality_assessment en lugar de accepted, y, si el feedback inicial es malo, los mensajes retenidos caen con el 132015. Una plantilla mala no espera al 131049 para quedar contenida.

Por último, no confundas el 131049 con el 131048. El 131049 trata de quien recibe; el 131048 trata de quien envía — restricción de envío porque mensajes anteriores del número fueron bloqueados o marcados como spam. El primero se resuelve con espera y relevancia; el segundo exige revisar la calidad del número en el Administrador de WhatsApp antes de enviar nada más. Y Meta es explícita en una diferencia que sorprende: en la Cloud API, “Message quality does not factor into per-user marketing message limits”. Una buena plantilla no consigue excepción en el límite por usuario; solo pasa los demás filtros.

Cómo medir el efecto en una campaña

El 131049 tiene que convertirse en métrica, y Meta no te la da hecha. La página Analytics enumera los campos analytics, pricing_analytics y template_analytics de la cuenta, y ninguno separa los fallos por código: pricing_analytics solo cuenta mensajes entregados, y template_analytics devuelve enviados, entregados, leídos y con clic. La diferencia entre enviados y entregados mezcla 131049, 130472, 131026 y todo lo demás. La fuente del número correcto es tu propio registro de webhooks.

El registro mínimo, según nuestra experiencia, tiene cuatro campos por fallo: el wamid, el código, el instante del failed y la campaña o el envío de origen. Con ellos se puede calcular, por campaña y por segmento, la proporción de destinatarios que volvió con 131049 — y vigilar si sube. Una tasa que crece de campaña en campaña sobre la misma base es señal de saturación: las mismas personas recibiendo demasiado marketing, tuyo y de los demás.

Compara segmentos por lo que mide el límite. Si el criterio de Meta es el engagement reciente, quien leyó, hizo clic o respondió en las últimas semanas tiende a recibir, y quien lo ignora todo desde hace meses tiende a chocar con el límite. Separar la base por recencia de interacción y mirar el 131049 en cada parte convierte un error opaco en un indicador de calidad de la lista — y muestra dónde conviene enviar menos, o enviar otra cosa.

En cuanto al coste, la regla de la página Pricing es que la empresa solo paga los mensajes entregados, y la referencia del webhook de estado muestra el objeto pricing acompañando a sent, delivered y read, no a failed. El 131049 no aparece en la factura de Meta. Aparece en otro sitio: cada rechazo es una persona de la campaña que no vio la oferta — y, con un reintento apresurado, una persona que tampoco la verá mañana.

La Marketing Messages API, y el fin del marketing en la Cloud API

Meta tiene una API aparte para marketing, la Marketing Messages API for WhatsApp, que empezó como MM Lite y salió de la beta el 19 de noviembre de 2025, ya con el nombre nuevo. La diferencia que importa aquí está en la página Features: tiene en cuenta si el mensaje es de alto engagement al decidir la entrega, y Meta habla de “up to 9% more messages” entregados frente a la Cloud API, donde la calidad del mensaje no entra en el límite por usuario.

La cifra tiene contexto, y la propia Meta lo da en una nota al pie: una prueba A/B con unos 12 millones de mensajes de anunciantes en la India, en enero de 2025, comparando solo mensajes de alto engagement. Es decir, la API nueva no elimina el 131049. Los códigos de error son los mismos, y la restricción para números de Estados Unidos también vale en ella. Mejora la entrega de lo que ya es relevante; no salva lo que no lo es.

La noticia más grande salió el 13 de octubre de 2026, en la página Overview de la misma API: la Cloud API va a dejar de aceptar marketing. Las cuentas de mensajería creadas a partir del 13 de abril de 2027 ya no podrán enviar marketing por la Cloud API; las creadas antes siguen hasta el 13 de octubre de 2027, cuando enviar marketing por la Cloud API empezará a devolver un error. Utility, autenticación y atención siguen en la Cloud API como están.

Para quien integra, es una migración con plazo — Meta calcula unas dos semanas para la mayoría de las integraciones. El marketing pasa a salir por POST /<PHONE_NUMBER_ID>/marketing_messages, que solo acepta plantillas de marketing, con product_policy en CLOUD_API_FALLBACK o STRICT. Y Meta pide vigilar el tráfico reclasificado: las plantillas utility que recategorizó como marketing tienen que ir por la API nueva, así que la integración necesita saber la categoría actual de cada plantilla, y el webhook template_category_update existe para eso. Quien lo deje para octubre de 2027 se enterará del plazo por el error.