Si tu empresa integro la API de WhatsApp Business hace un par de años, es muy probable que este operando sobre supuestos que ya no son ciertos. Dos cambios de fondo han reescrito las reglas: la API On-Premises, la que se instalaba en servidores propios, llego a su fin el 23 de octubre de 2025, y desde el 1 de julio de ese mismo año Meta dejo de facturar por conversaciones de 24 horas para cobrar por cada mensaje de plantilla entregado. La mayor parte del contenido en español sobre esta API sigue describiendo el modelo antiguo, así que no es raro encontrar equipos técnicos planificando integraciones sobre una arquitectura de precios y de infraestructura que ya no existe.
Esta guía la firma Miguel Quílez, director de Hiberus Booster, la unidad de aceleración digital e IA de Hiberus, primera consultora tecnológica española de capital privado con más de 4.000 profesionales y +250 millones de euros de ingresos. Está pensada para equipos técnicos y de negocio que usan o van a integrar WhatsApp Business API y necesitan saber que ha cambiado antes de firmar un presupuesto o de escribir una línea de código.
Qué cambió de verdad en la API de WhatsApp Business en 2026
Conviene separar dos cambios que a menudo se mezclan porque llegaron con meses de diferencia pero apuntan en la misma dirección: menos control local, más dependencia directa de la infraestructura de Meta y una factura que responde a un modelo distinto.
- Infraestructura. La API On-Premises, que permitía alojar el motor de mensajería en servidores propios, dejó de estar operativa el 23 de octubre de 2025. La única vía soportada hoy es la Cloud API, alojada directamente por Meta.
- Facturación. Desde el 1 de julio de 2025, Meta cobra por mensaje de plantilla entregado, no por conversación de 24 horas como hacía antes. El modelo de conversaciones quedó deprecado esa misma fecha.
Ninguno de los dos cambios es una nota a pie de página: el primero obliga a migrar arquitectura, y el segundo cambia directamente cómo se calcula el coste de cualquier flujo de mensajería que ya esté en producción.
El fin de la API On-Premises: la fecha límite ya pasó
El 23 de octubre de 2025 es la fecha de end of life de la API On-Premises de WhatsApp Business. A partir de ese momento, cualquier intento de registrar un número de teléfono en esa infraestructura devuelve un error 1005. No es un aviso de que el soporte se va a retirar pronto: es que la vía ya no admite altas nuevas.
La consecuencia práctica es que la única forma viable de operar WhatsApp Business API en 2026 es la Cloud API, alojada por Meta. Para equipos que construyeron su integración sobre servidores propios, esto implica una migración real: cambia el modelo de despliegue, cambia cómo se gestionan las credenciales y cambia la forma en la que se monitoriza el envío de mensajes. No es una actualización menor de librería, es un cambio de proveedor de infraestructura de facto.
El modelo de facturación cambió: de conversaciones de 24h a pago por mensaje
Hasta el 30 de junio de 2025, Meta facturaba por conversaciones: una ventana de 24 horas que, una vez abierta por un mensaje de plantilla o por una respuesta del usuario, permitía intercambiar mensajes sin coste adicional dentro de esa franja. Desde el 1 de julio de 2025, ese modelo quedó deprecado y Meta pasó a facturar por mensaje de plantilla entregado, sin la lógica de ventana de conversación.
| Aspecto | Modelo anterior (hasta 30-jun-2025) | Modelo actual (desde 1-jul-2025) |
|---|---|---|
| Unidad de cobro | Conversación de 24 horas | Mensaje de plantilla entregado |
| Lógica de ventana | Una conversación abierta permitía varios mensajes sin coste extra dentro de 24h | No hay ventana: cada plantilla entregada se factura de forma individual |
| Vigencia | Deprecado el 1 de julio de 2025 | Vigente desde el 1 de julio de 2025 |
| Estado del contenido en español | Es lo que describe la mayoría de artículos y tutoriales aún hoy | Poca documentación en español lo refleja correctamente |
La implicación directa es que cualquier estimación de coste hecha con la lógica de "una conversación cubre varios mensajes" ya no aplica. Si tu proveedor, tu partner técnico o tu propia documentación interna siguen hablando de conversaciones de 24 horas, esa referencia quedó obsoleta el 1 de julio de 2025 y conviene revisar el cálculo de coste real de tu volumen de mensajería.
Las tres categorías de plantilla y por qué importan
Todo mensaje saliente basado en plantilla en WhatsApp Business API se clasifica en una de tres categorías: MARKETING, UTILITY y AUTHENTICATION. La categoría no es un metadato decorativo: condiciona la revisión de la plantilla, su aprobación y, con el modelo de facturación per-message vigente, el coste de cada envío.
Elegir la categoría correcta al dar de alta una plantilla es, por tanto, una decisión con impacto económico directo, no un trámite de formulario. Una plantilla de recordatorio de cita declarada como UTILITY y una plantilla de oferta comercial declarada como MARKETING deberían ser evidentes, pero la zona gris —confirmaciones con contenido promocional, notificaciones que incluyen upsell— es donde se concentran los problemas.
Por qué Meta reclasifica tus plantillas UTILITY como MARKETING
Desde el 9 de abril de 2025, Meta aplica una revisión más estricta sobre las plantillas declaradas como UTILITY. Si el sistema de revisión considera que el contenido es en realidad de marketing, no rechaza la plantilla: la aprueba, pero reclasificada como MARKETING. La plantilla funciona igual, pero se factura con la categoría reclasificada, no con la que declaró quien la envió.
Esto es exactamente lo que hace que muchos equipos técnicos descubran el problema tarde: la plantilla se aprueba, el flujo funciona en producción, y nadie revisa de nuevo la categoría con la que realmente se está facturando cada envío hasta que alguien audita la factura mensual.
El error típico: un equipo diseña una plantilla de "confirmación de pedido" o "recordatorio" con un par de líneas que en realidad son promocionales (un descuento, una llamada a la acción de compra) y la declara como UTILITY porque el propósito principal es transaccional. Meta la aprueba, pero reclasificada como MARKETING. Nadie se entera hasta que revisa el detalle de facturación semanas después, y para entonces ya se han acumulado envíos facturados a un precio que nadie presupuestó.
El rechazo más frecuente: INCORRECT_CATEGORY
El motivo de rechazo más común en la revisión de plantillas de WhatsApp Business API es INCORRECT_CATEGORY: la categoría declarada no coincide con lo que el sistema de revisión de Meta detecta en el contenido. Cuando esto ocurre, hay un plazo de 60 días para apelar la decisión.
Este dato tiene una consecuencia operativa concreta: si una integración depende de plantillas nuevas para lanzar una campaña o un flujo transaccional, dar por hecho que la categoría declarada se va a aceptar sin revisión es un riesgo de calendario. Conviene tratar la clasificación de cada plantilla como una decisión que se revisa antes de enviarla a aprobación, no como un campo que se rellena por rutina.
Los límites de mensajería escalan solos, si no rompes la calidad
Además de la facturación, WhatsApp Business API impone messaging limits: un tope de destinatarios únicos a los que se puede iniciar conversación en 24 horas. Estos límites se aplican por portfolio (no por número individual) y escalan en tramos fijos: 250, 1.000, 2.000, 10.000, 100.000 y, finalmente, sin límite.
El escalado de un tramo al siguiente es automático, no hay que solicitarlo. Ocurre en aproximadamente 6 horas cuando, en los últimos 7 días, se ha utilizado al menos la mitad del límite vigente manteniendo una calidad de mensajería alta. Dicho de otro modo: crecer en volumen de envío es la condición necesaria, pero la calidad (tasas de bloqueo, de reporte como spam, de entrega) es la condición que decide si ese crecimiento se traduce en más capacidad o en un techo que no se mueve.
Cómo te ayuda Hiberus Booster
Hiberus Booster acompaña a empresas que ya usan o quieren integrar WhatsApp Business API en su producto o en sus procesos de atención y comunicación con clientes. En la práctica, eso significa auditar si la integración actual sigue apoyada en la API On-Premises ya retirada, revisar la categoría real con la que se están facturando las plantillas en producción, y diseñar el flujo de mensajería con la Cloud API y el modelo per-message como punto de partida, no como un ajuste posterior. El respaldo es el de un grupo con más de 4.000 profesionales, certificaciones ISO 27001, 27701 y 42001, y casos productivos en banca, industria, retail y sector público. Primera conversación gratuita y sin compromiso.
El 95% de las propuestas de Hiberus en 2026 incorporan IA. En proyectos reales esto se traduce en resultados como una migración de sistemas legacy un 60% más rápida en Banco Pichincha, 3.250 horas/año ahorradas en Mercedes-Benz Vitoria o un 30% de reducción del time to market en SAICA.
Habla con Hiberus Booster sobre tu integración de WhatsApp
Cuéntanos en qué punto está tu integración y un especialista te responde en menos de 24 horas. Primera conversación gratuita, sin compromiso.
✓ ¡Recibido!
Gracias. Un especialista de Hiberus Booster te contacta en menos de 24 horas.
Preguntas frecuentes sobre la API de WhatsApp Business
¿Cuándo dejó de funcionar la API On-Premises de WhatsApp Business?
Llegó a su end of life el 23 de octubre de 2025. Desde esa fecha, cualquier intento de registrar un número en ella devuelve el error 1005. La única vía viable hoy es la Cloud API alojada por Meta.
¿Cuál es la única alternativa a la API On-Premises hoy?
La Cloud API de WhatsApp Business, alojada directamente por Meta. Tras el end of life de la API On-Premises el 23 de octubre de 2025, no existe otra vía oficial soportada para integrar WhatsApp Business API en un producto propio.
¿Cómo cobra Meta los mensajes de WhatsApp Business API desde julio de 2025?
Desde el 1 de julio de 2025, Meta factura por mensaje: se cobra por cada mensaje de plantilla entregado. El modelo anterior, basado en conversaciones de 24 horas, quedó deprecado en esa misma fecha. Buena parte del contenido en español que circula todavía describe el modelo antiguo.
¿Qué categorías de plantilla existen en WhatsApp Business API?
Tres: MARKETING, UTILITY y AUTHENTICATION. La categoría que se declara al crear la plantilla condiciona su revisión, su aprobación y su facturación, por lo que elegirla bien no es un trámite menor.
¿Por qué Meta reclasifica una plantilla UTILITY como MARKETING?
Desde el 9 de abril de 2025, si Meta considera que una plantilla enviada como UTILITY es en realidad contenido de marketing, la aprueba pero reclasificada como MARKETING, y se factura como tal. El motivo de rechazo más frecuente en plantillas es precisamente INCORRECT_CATEGORY, con un plazo de 60 días para apelar la decisión.
¿Cómo funcionan los límites de mensajería (messaging limits) de WhatsApp Business API?
Se aplican por portfolio y escalan en tramos: 250 destinatarios únicos en 24 horas, luego 1.000, 2.000, 10.000, 100.000 y finalmente sin límite. El escalado es automático y tarda unas 6 horas si en los últimos 7 días se ha usado al menos la mitad del límite vigente manteniendo una calidad alta.