Categoría de plantilla en WhatsApp: por qué tu utility pasó a marketing

La categoría decide precio, límite y ruta

La página Template categorization de la documentación de la Cloud API empieza diciendo que las categorías existen a efectos de precio, y es verdad: desde julio de 2025 Meta cobra por mensaje entregado, y el importe depende de la categoría y del país de quien recibe. Marketing, utility y autenticación tienen precios distintos, y los tramos de descuento por volumen solo existen para utility y autenticación. Cambiar la categoría de una plantilla es cambiar el precio de cada mensaje que envía.

Pero la categoría decide más que el precio. El límite de marketing por usuario, que devuelve el error 131049 cuando una persona ya recibió demasiado marketing de todas las empresas juntas, solo vale para marketing. La restricción que impide entregar marketing a números de Estados Unidos, también. Una plantilla de aviso de entrega que pasa a marketing empieza a competir en la bandeja de entrada con las promociones de todo el mundo — y deja de llegar a clientes con número estadounidense.

Y, a partir de 2027, la categoría decide la ruta. El 13 de octubre de 2026 Meta anunció en la página Overview de la Marketing Messages API que la Cloud API dejará de aceptar marketing: las cuentas de mensajería creadas a partir del 13 de abril de 2027 ya no envían marketing por ella, y el 13 de octubre de 2027 enviar marketing por la Cloud API empezará a devolver un error. La misma página pide revisar el tráfico reclasificado, porque la utility recategorizada como marketing tiene que salir por la API nueva.

El precio también cambió de forma en octubre de 2026. Entre julio de 2025 y septiembre de 2026, la utility enviada con la ventana de atención abierta era gratis; desde el 1 de octubre de 2026 se vuelve a cobrar, según la página Pricing. El marketing nunca fue gratis dentro de la ventana. La cuenta de una recategorización, por tanto, es más sencilla de hacer y más fácil de equivocar: es la diferencia entre el precio de utility y el de marketing, en cada mensaje, con la ventana abierta o cerrada.

Qué hace que una plantilla sea utility

La definición de Meta tiene dos condiciones, y las dos tienen que cumplirse a la vez. La primera es no ser promocional: nada de intención de vender, persuadir o estimular una compra. La segunda es ser específica del usuario o solicitada por él — vinculada a su pedido, cuenta, servicio o transacción — o, en su lugar, ser esencial o crítica para él, como una alerta de seguridad. Si falta cualquiera de las dos, no es utility.

La página enumera cinco objetivos que caben en utility. Gestión del opt-in: confirmar la suscripción hecha en otro canal o la petición de baja. Gestión de pedidos: confirmar, actualizar o cancelar, con datos del pedido en el cuerpo — número, seguimiento, reembolso procesado. Alertas y novedades de la cuenta sobre lo que el cliente ya compró o tiene contratado. Encuestas de satisfacción sobre una compra o una atención concreta. Y continuar en WhatsApp una conversación que empezó en otro canal, siempre que el cliente lo haya pedido.

Los ejemplos de Meta ayudan a calibrar el límite. Es utility el aviso de que el cargo mensual se hará en la tarjeta guardada, el saldo diario de la cuenta e incluso el aviso de que quedan pocos minutos en el plan, con la fecha para recargar. La petición de recargar no vuelve promocional la plantilla, porque se refiere a un servicio que el cliente ya tiene y necesita conocer. La palabra que inclina la balanza es descuento: la misma suscripción a punto de vencer, con una oferta para renovar, ya es marketing.

Están también los casos esenciales, que no dependen de una petición del cliente pero tienen que seguir sin ser promocionales: seguridad pública, como una alerta de temporal; servicio público, como campañas de salud y plazos de inscripción electoral; interrupciones, como una caída del sistema; protección de la cuenta o del producto, como alertas de fraude y retiradas de producto; y obligaciones legales, como un cambio en la política de privacidad. Es una lista corta a propósito.

Qué es marketing aunque no lo parezca

Marketing es la categoría más flexible, y Meta mete en ella todo lo que no encaja con claridad en las otras dos. Dos reglas prácticas salen directamente de la documentación. El contenido mixto es marketing: una actualización de pedido con una promoción, o una encuesta de satisfacción con una oferta, deja de ser utility por la parte promocional. Y el contenido poco claro es marketing: una plantilla cuyo cuerpo es solo {{1}}, o solo “¡Enhorabuena!”, no le da a Meta forma de saber qué se va a enviar, y decide por el lado más amplio.

La tercera regla sorprende más: el retargeting es marketing aunque el cliente lo haya pedido. Los ejemplos de la página son los que más rompen expectativas. El carrito abandonado es marketing. La suscripción a punto de vencer con descuento para renovar es marketing. La solicitud de préstamo pendiente con una invitación a entrar y continuar es marketing. El coche encontrado en la búsqueda guardada del cliente es marketing. También lo son la felicitación de cumpleaños y el agradecimiento por la compra con un porcentaje de descuento.

El ejemplo más contraintuitivo es la disculpa: avisar de que la entrega se retrasó y de que, por eso, se ha abonado un crédito en la cuenta del cliente es marketing para Meta. La lógica es la misma — el crédito es un estímulo para la próxima compra, y el aviso dejó de ser solo un aviso. La presentación de un asistente virtual nuevo también entra como marketing, porque promociona un servicio en lugar de responder a algo que hizo el cliente.

La regla se aplica a plantillas muy habituales. La factura emitida, con importe y vencimiento, es utility; la misma factura con “paga hoy y llévate un 5% de descuento” es marketing. La confirmación de una cita es utility; el recordatorio de que han pasado seis meses desde la última visita, invitando a reservar otra, tiende a ser marketing. La propia Meta avisa de que los ejemplos son ilustrativos y de que un texto parecido puede caer en otra categoría según el contenido exacto — pero la dirección es siempre la misma: ante la duda, la balanza se inclina hacia marketing.

Autenticación, la categoría más estrecha

La autenticación sirve para una sola cosa: verificar la identidad de alguien con un código de un solo uso. Es también la única categoría que puede enviar ese código — un OTP en una plantilla utility o de marketing está fuera de las reglas. Los requisitos son estrictos: usar las plantillas de autenticación de la biblioteca de Meta, configurar un botón de código (copiar el código o autocompletar con un toque), no usar URL, multimedia ni emojis, y limitar los parámetros a 15 caracteres.

El camino de la recategorización aquí es distinto, y más duro. Cuando Meta concluye que una plantilla de marketing o utility debería ser de autenticación, avisa con antelación, pero no cambia la categoría: el primer día del mes siguiente, la plantilla pasa a REJECTED y deja de enviar. A partir de ahí, el envío con ella falla como el de cualquier plantilla que no está aprobada.

La salida que recomienda Meta es migrar antes del plazo a una plantilla de autenticación de la biblioteca, no recurrir: las plantillas marcadas para rechazo por deber ser de autenticación no entran en el proceso de revisión. Si envías códigos de verificación en una plantilla utility por costumbre, el aviso es el momento de cambiar — después del día 1, el código sencillamente no llega.

Al crearla: la utility que vuelve aprobada como marketing

Cuando creas una plantilla, indicas la categoría, y Meta la comprueba con el contenido. Hasta abril de 2025, el desacuerdo podía acabar en rechazo. Desde el 9 de abril de 2025, una plantilla enviada como UTILITY que Meta considera marketing se aprueba como MARKETING, sin rechazo — y el parámetro allow_category_change, que durante años permitió o impidió ese cambio, se retiró en la misma fecha. Hay guías antiguas que todavía lo recomiendan como protección. Ya no protege nada.

La consecuencia es que “aprobada” dejó de responder a la pregunta que importa. La categoría con la que se aprobó la plantilla llega en la respuesta de creación y en el webhook message_template_status_update, y es esa la que hay que guardar — no la que pedía el formulario. El rechazo por categoría sigue existiendo, con el motivo INCORRECT_CATEGORY, pero el caso más habitual ahora es el silencioso: aprobada, solo que en otra categoría.

Dos reglas de la página Utility templates completan el cuadro. Crear o editar una plantilla utility con material de marketing hace que Meta la recategorice automáticamente como marketing — editar una plantilla aprobada para añadir una oferta es el camino más corto para perder la categoría. Y las plantillas de la biblioteca de Meta ya vienen categorizadas como utility o autenticación; personalizar una de ellas hace que la plantilla pase de nuevo por revisión.

En producción: aprobada no es definitiva

La categoría también cambia después de la aprobación. Desde julio de 2024 Meta ejecuta un proceso recurrente que busca plantillas aprobadas que deberían estar en otra categoría. En la versión de septiembre de 2026 de la página Template categorization, el alcance de ese proceso creció: vale para cualquier plantilla aprobada que no cumpla las directrices, sea porque se aprobó fuera de ellas, sea “because the messages the template sends do not meet them” — y eso incluye plantillas cuya categoría ya se había confirmado en una revisión.

Nuestra lectura de este cambio, que es una inferencia y no está escrita así en la documentación: lo que va en las variables pasó a contar. Una plantilla utility aprobada con el cuerpo “Tu pedido {{1}} se ha actualizado: {{2}}” puede ser impecable como texto y pasar a marketing por lo que la integración rellena en {{2}} cada día. La revisión aprobó el molde; la recategorización en producción mira lo que salió de él.

Cuando Meta concluye que una utility debería ser marketing, avisa con un día de antelación, y en el plazo la categoría pasa a MARKETING. El estado sigue siendo APPROVED y la plantilla sigue enviando — eso es lo que hace peligroso el cambio. Nada falla, ningún envío se rechaza, y cada mensaje desde ese momento cuesta como marketing y sigue las reglas del marketing. Para quien ya recibió una advertencia por uso indebido, ni siquiera hay aviso: desde el 16 de abril de 2025, el cambio es instantáneo, y el correo y el webhook solo lo confirman.

El aviso llega por varios caminos: correo a quien tiene control total de la cuenta, un icono en la lista de plantillas con la categoría de destino y la fecha, un banner con un CSV en el Administrador de WhatsApp, la lista en el Business Support Home y el webhook template_category_update. De todos ellos, solo el último entra en tu sistema sin que nadie tenga que abrir nada. Lo vimos en nuestra propia operación: Meta reclasificó como marketing una plantilla utility, y la lección se quedó en el código — la categoría guardada en la base de datos es una copia, y una copia desactualizada hace que la estimación de coste de una campaña mienta.

El webhook que avisa, y la trampa del nombre del campo

El template_category_update se dispara en dos momentos: cuando la categoría de una plantilla va a ser cambiada por el proceso automático, y cuando ya se cambió, manualmente o por el proceso. Los dos eventos traen message_template_id, message_template_name y message_template_language. Lo que cambia entre ellos son los campos de categoría — y ahí está la trampa.

En el aviso previo, la referencia del webhook trae tres campos: correct_category, que es la categoría que tendrá la plantilla dentro de 24 horas; category_update_timestamp, el momento programado del cambio, en segundos Unix; y new_category, que, pese al nombre, es la categoría actual. En el cambio ya hecho, los campos son previous_category y new_category, y entonces sí new_category es la nueva. Quien lee new_category en los dos eventos como “la categoría de aquí en adelante” pierde el aviso entero — y solo descubre el cambio cuando ya ha ocurrido.

El tratamiento correcto separa los dos casos por los campos presentes. Con correct_category y category_update_timestamp, es un aviso: registra el cambio programado, avisa a quien es responsable de la plantilla y usa las 24 horas para decidir entre ajustar el texto, aceptar la nueva categoría o prepararte para recurrir. Con previous_category, es un hecho consumado: actualiza la categoría guardada y recalcula lo que depende de ella — estimaciones de coste, reglas de límite, la ruta de envío.

Si no quieres depender solo del webhook, la API permite comprobarlo: un GET en message_templates con fields=category,correct_category muestra, para cada plantilla, la categoría actual y la categoría a la que va, cuando hay un cambio programado. Y, para cada mensaje, el webhook de estado trae pricing.category — la categoría en la que ese mensaje se clasificó realmente. Es la fuente para comprobar un cargo, porque es la que usó Meta.

Revisión, penalizaciones y el 131064

Se puede pedir la revisión de una recategorización, pero solo desde el panel. El camino es el Administrador de WhatsApp: en la lista de plantillas, el banner lleva al Business Support Home, en el apartado de cambios de categoría de plantillas, donde se selecciona la plantilla y se solicita la revisión. No existe un endpoint de API para ello. El plazo es de 60 días desde el cambio de categoría, y la documentación no promete plazo de respuesta. El resultado aparece en pestañas: en revisión, sin cambios o revertida — y, si se revierte, la plantilla vuelve a su categoría anterior.

Revertir no da inmunidad. Desde la actualización de septiembre de 2026, Meta puede volver a actuar sobre una plantilla ya confirmada en una revisión si los mensajes enviados después no cumplen las directrices. Y quien clasifica marketing como utility de forma reiterada entra en una escalera de restricciones descrita en la misma página: advertencia; límite al volumen de utility en una ventana continua de 24 horas, con el exceso rechazado, durante al menos siete días; restricción de utility, en la que todas las plantillas utility aprobadas de la cuenta pasan a marketing y crear utility queda bloqueado siete días, o 30 si hay reincidencia; y, por último, la misma restricción en todas las cuentas del portfolio, durante 30 días.

Cada escalón llega por el webhook account_update, con el evento ACCOUNT_RESTRICTION, un violation_type como UTILITY_TEMPLATE_ABUSE o UTILITY_TEMPLATE_ABUSE_RATE_LIMIT y, cuando hay una restricción activa, un restriction_info con el tipo y la fecha en que expira. Ese webhook merece una alerta con responsable: es el único aviso de que toda la cuenta ha pasado a tratarse como sospechosa.

El error que acompaña al límite es el 131064, que la página Error codes describe como límite de mensajes alcanzado por infracciones de clasificación de plantillas, válido para plantillas y para Direct Send. La solución indicada es revisar las categorías; la restricción se levanta sola al final del periodo de penalización. Una confusión habitual, que repiten algunos proveedores, es que el 131064 bloquea todos los envíos. Según la escalera de la documentación, el límite afecta al volumen de utility — el marketing y la autenticación siguen saliendo. Lo que se bloquea es justo el mensaje que debería ser el más importante: el aviso transaccional.

Cómo escribir una utility que siga siendo utility

La regla que resuelve la mayoría de los casos es separar. Una plantilla para el aviso, otra para la oferta. El aviso de pedido enviado lleva el número de pedido, el código de seguimiento y nada más; el cupón para la próxima compra va en una plantilla de marketing, enviada a quien aceptó recibir marketing. Juntar las dos para ahorrarse un mensaje sale más caro que enviar ambas, porque el mensaje combinado es marketing entero.

Después, anclar el cuerpo en la transacción. La utility es específica, y la especificidad se ve en el texto: número de pedido, fecha de la cita, importe de la factura, últimos dígitos de la tarjeta. Un cuerpo genérico con una sola variable es exactamente lo que Meta llama contenido poco claro. Y, ahora que la recategorización mira los mensajes enviados, la disciplina vale para lo que la integración mete en las variables, no solo para la plantilla aprobada.

Cuidado también con el vocabulario. Descuento, cupón, aprovecha, novedades, oferta por tiempo limitado e invitaciones a conocer otro producto empujan la plantilla hacia marketing, incluso dentro de un aviso legítimo. Una encuesta de satisfacción tiene que citar la compra o la atención de la que trata; la genérica, sobre la experiencia con la marca, no pasa como utility. Y la invitación a continuar la conversación en WhatsApp solo es utility cuando el cliente pidió cambiar de canal.

Por último, trata la categoría como un dato vivo. Guarda la categoría que aprobó Meta, no la que pediste; suscríbete a template_category_update, message_template_status_update y account_update; lee correct_category como aviso y previous_category como hecho; y revisa pricing.category cuando las cuentas no cuadren. Con el fin del marketing en la Cloud API fijado para 2027, saber la categoría actual de cada plantilla deja de ser un detalle de facturación y pasa a decidir por dónde sale el mensaje.