Cloud API vs On-Premises: la decisión que casi nadie entiende y que cuesta dinero cada mes

Las diferencias que importan en el día a día

Dejando de lado el vocabulario técnico, seis diferencias aparecen en la operación:

• Quién mantiene el servidor. En Cloud API, Meta. En On-Premises, tú o tu proveedor — incluyendo actualización de versión, que tenía plazo y se volvía urgente cuando se olvidaba.
• Actualizaciones y nuevos recursos. Los recursos nuevos llegan primero a Cloud API. Quienes quedaron en el modelo antiguo empezaron a recibir menos, y más tarde.
• Escala en picos. En Cloud API, la capacidad es de Meta. En On-Premises, un envío grande exigía dimensionar máquina, y la falta de capacidad se volvía cola bloqueada.
• Costo de infraestructura. Cloud API no tiene costo de servidor. On-Premises sumaba máquina, base, backup y equipo de mantenimiento.
• Por dónde pasan los mensajes. En Cloud API, por la infraestructura de Meta. Este era el principal argumento de quienes defendían el modelo antiguo en sectores con exigencia de dato local.
• Soporte. En Cloud API, problema de plataforma es problema de Meta. En On-Premises, la primera pregunta siempre era si el error estaba en tu contenedor.

Quién usaba On-Premises y por qué

Tres motivos sustentaban la elección por el modelo antiguo, y vale entenderlos porque explican la resistencia de algunas empresas a migrar.

El primero era exigencia regulatoria o interna sobre dónde los datos circulan y quedan almacenados, común en bancos, salud y sector público. El segundo era latencia e integración con sistemas internos: empresas con ERP pesado y reglas propias preferían tener el componente de WhatsApp cerca del resto de la arquitectura. El tercero era simplemente historia — quien empezó antes de que existiera Cloud API montó todo en ese modelo y no tuvo motivo para cambiar mientras funcionaba.

Lo que cambió es que los dos primeros motivos perdieron fuerza con el tiempo, a medida que Meta amplió controles y opciones de procesamiento, mientras el costo de continuar en el modelo antiguo subió: menos recursos, menos soporte y un plazo de descontinuación corriendo.

Cómo saber en cuál estás hoy

La mayoría de las empresas no sabe, porque contrató un proveedor y nunca preguntó. Tres caminos rápidos para descubrirlo:

• Pregunta directamente al proveedor, por escrito: "¿mi número está en Cloud API o On-Premises?". La respuesta debe ser clara.
• Mira el panel de Meta. En el administrador de cuentas de WhatsApp Business, el número aparece vinculado a la cuenta comercial, y la forma de configuración da pistas claras.
• Observa los síntomas. Si los recursos nuevos tardan en llegar, si hubo algún aviso de actualización de versión del contenedor, o si el proveedor habla de "nuestro servidor de WhatsApp", probablemente sea el modelo antiguo.

Saber esto importa por un motivo práctico: si estás en On-Premises, hay una migración por delante, y es mejor planearla que ser sorprendido por un plazo.

Cómo funciona una migración

Migrar de On-Premises a Cloud API no es cambiar de número ni empezar de cero, pero tampoco es un botón. Lo que sucede, en líneas generales:

• el número se migra dentro de la misma cuenta comercial, manteniendo el mismo teléfono para el cliente;
• los templates aprobados están vinculados a la cuenta, no al servidor, y siguen disponibles;
• la integración debe apuntar a la nueva dirección, y el webhook debe ser reconfigurado;
• existe una ventana corta de indisponibilidad durante el cambio, que debe acordarse con la operación;
• la calidad y el límite de envío del número acompañan a la cuenta, no al servidor.

El punto de mayor atención es el historial de conversaciones. Vive en el sistema que usas, no en la API — y es exactamente por eso que la elección del sistema importa más que la elección del hospedaje. La empresa que atendía directo por la API, sin CRM, suele descubrir en la migración que no tiene historial para llevar.

Lo que no cambia entre los dos modelos

Esta es la parte que más sorprende a quienes esperan que Cloud API resuelva problemas que no son suyos. Continúan exactamente iguales en ambos modelos:

• Las reglas de Meta. Template aprobado para iniciar conversación, ventana de atención, categorías de mensaje y política de uso valen igual.
• La facturación por conversación. El modelo de precio de Meta es el mismo, y no depende del hospedaje.
• Calidad y límite de envío. El nivel del número y la clasificación de calidad siguen a la cuenta, y no mejoran por cambiar de modelo.
• Bloqueo y baneo. Quien denuncia es el cliente, y la consecuencia es la misma.
• Opt-in. Seguir necesitando permiso para enviar no es detalle técnico, es regla.

Es decir: si tu problema hoy es template rechazado, número con calidad baja o envío bloqueado, cambiar de Cloud API a On-Premises o viceversa no resuelve nada.

Seguridad y datos: lo que cada modelo realmente entrega

Este era el argumento más fuerte a favor de On-Premises y sigue siendo el más malentendido. La idea intuitiva es que mantener el servidor en casa significa que los datos "no salen de la empresa" — y eso nunca fue verdad. En cualquiera de los dos modelos, el mensaje circula por la red de WhatsApp, es entregado por la infraestructura de Meta al dispositivo del cliente y está sujeto a las políticas de la plataforma.

Lo que cambiaba en On-Premises era dónde estaba el componente que intermediaba el envío y dónde se procesaba el contenido en ese tramo específico. Para sectores con exigencia regulatoria sobre procesamiento local, eso hacía diferencia jurídica real. Para la gran mayoría de las empresas, no hacía diferencia práctica, y la sensación de control venía acompañada de un riesgo mayor: servidor mal mantenido, sin actualización y con backup improvisado es menos seguro que infraestructura administrada.

Hoy, la conversación útil sobre seguridad cambió de lugar. Ya no es sobre el hospedaje de la API, sino sobre quién tiene acceso a las conversaciones en el sistema que usas: existe control de permiso por usuario, el agente puede exportar toda la base, qué pasa cuando un vendedor sale de la empresa, quién puede ver la conversación de otro agente, y cómo se registra quién hizo qué. Ahí es donde ocurre la verdadera fuga — en el acceso indebido de quien ya está dentro, no en el tramo de red entre tú y Meta.

Por qué el proveedor importa más que el hospedaje

Desde el punto de vista de quien usa, el hospedaje de Meta es invisible. Lo que se ve todos los días es lo que está encima: la pantalla de atención, el historial, la automatización, los reportes, la velocidad de soporte, la estabilidad de las integraciones.

Dos empresas pueden estar en la misma Cloud API y tener experiencias opuestas, porque una tiene un sistema que guarda conversación, distribuye leads, automatiza respuestas y muestra resultados, y la otra tiene una bandeja de entrada genérica que pierde mensajes cuando se cierra el navegador. El hospedaje es el mismo; el negocio no.

Al elegir, las preguntas que realmente cambian el resultado son: ¿el historial es mío y puedo exportarlo?; ¿cuántos agentes caben en el mismo número?; ¿existe automatización real o solo respuesta automática?; ¿el sistema muestra tiempo de primera respuesta y conversión?; y ¿cuánto tarda el soporte en responder cuando el envío se detiene un viernes por la noche?

Coexistencia, código QR y por qué esto es otra conversación

Una confusión frecuente mezcla tres cosas diferentes: Cloud API, On-Premises y las soluciones no oficiales basadas en lectura de código QR. Las dos primeras son hospedajes de la API oficial. La tercera no es API oficial — es un software que se conecta a WhatsApp como si fuera un celular pareado.

La diferencia práctica es grande. En la API oficial, existe contrato, template aprobado, cobro por conversación, soporte y previsibilidad. En la conexión por código QR, no existe aprobación previa de mensaje ni costo por conversación, lo que atrae a mucha gente, pero tampoco existe garantía alguna: el número puede ser bloqueado en cualquier momento, sin aviso y sin recurso, y el comportamiento de envío es justamente lo que más dispara bloqueos.

Existe además la coexistencia, que permite usar la aplicación WhatsApp Business y la API oficial en el mismo número, con reglas propias definidas por Meta. Resuelve un problema específico — mantener el historial y el uso en el celular mientras la empresa entra en la API — y no sustituye la decisión de hospedaje.

La lectura correcta es ver dos ejes independientes. Uno es el canal: oficial o no oficial. El otro, dentro del oficial, es el hospedaje: Cloud o On-Premises. Mezclar los dos ejes lleva a decisiones malas, como elegir código QR pensando que es "la versión barata de la API oficial" cuando, en realidad, es una categoría diferente, con riesgo diferente y sin ninguna de las garantías que hacen que una empresa elija el camino oficial.

El costo real de cada modelo

Comparación para una operación media, con un número y cerca de seis mil conversaciones por mes:

• Cloud API: costo de las conversaciones cobrado por Meta + mensualidad del sistema de atención. Infraestructura: cero.
• On-Premises: costo de las conversaciones cobrado por Meta + mensualidad del sistema + servidor y base de datos + backup + tiempo de equipo técnico para actualización y monitoreo.

En una operación real con servidor dedicado modesto, backup y cerca de cuatro horas mensuales de trabajo técnico, el modelo antiguo añadía algo entre R$ 600 y R$ 1.400 por mes de costo que simplemente no existe en Cloud API — sin entregar nada más para quien atiende. Para empresas con exigencia específica de procesamiento de datos, ese costo se justificaba. Para todas las demás, era costo puro.

Los errores más comunes en esta decisión

• Creer que el hospedaje resuelve problemas de calidad de número o de template rechazado.
• Elegir proveedor por el precio de la mensualidad sin preguntar si el historial es exportable.
• Posponer la migración de On-Premises hasta que se vuelva urgente con plazo.
• Migrar sin reconfigurar el webhook y quedarse sin recibir mensajes por días.
• No acordar la ventana de indisponibilidad con el equipo de atención.
• Confundir Cloud API con la aplicación WhatsApp Business, que son cosas completamente diferentes.

Por dónde empezar

Si estás empezando ahora, la respuesta es simple: Cloud API, con un proveedor que entregue historial tuyo y exportable. Si ya operas, descubre por escrito en qué modelo estás; si es On-Premises, pide al proveedor el plan de migración con fecha, ventana y responsable de reconfigurar el webhook; y aprovecha la migración para revisar lo que realmente importa — si tu sistema guarda el historial, si la automatización funciona y si puedes medir tiempo de respuesta y conversión. El hospedaje es una decisión única; el sistema encima es lo que usas todos los días.