WhatsApp Cloud API vs. On-Premise API:¿Cuál deberías usar en 2026?
21 de mayo de 2026
·
12 min de lectura
En este artículo: La respuesta de 60 segundos · Dos arquitecturas · Tabla de comparación completa · El timeline de deprecación · Throughput & rate limits · Desglose real de costos · El webhook entrante del que nadie habla · Qué cambia cuando migras · FAQ
La respuesta de 60 segundos
En 2026, esto no es una elección. La WhatsApp On-Premise API alcanzó end-of-life oficial el 23 de octubre de 2025. Meta dejó de enviar security patches, dejó de aceptar nuevas registraciones de números el 15 de enero de 2024, y ha marcado el stack On-Premise como software no soportado. Si aún estás corriendo un contenedor Docker self-hosted, estás en infraestructura muerta.
La WhatsApp Cloud API — donde Meta hostea el servidor, maneja el scaling, envía patches, y pushea mensajes entrantes a tu URL de webhook — ha sido el default para cada nuevo número de WhatsApp Business desde mediados de 2022. La Cloud API es más barata, más rápida de provisionar, mayor throughput, y recibe nuevas features primero. No hay escenario en 2026 donde On-Premise sea la respuesta correcta para una nueva integración.
Tanto la Cloud API como la On-Premise API son técnicamente parte de la "WhatsApp Business Platform". El branding es idéntico. La arquitectura es completamente diferente — y entender la arquitectura es la única forma de entender por qué ganó la Cloud API.
WhatsApp Cloud API (alojada por Meta)
Tu aplicación envía un HTTP POST a https://graph.facebook.com/v21.0/{phone_number_id}/messages. Meta lo recibe, rutea el mensaje a través de su backend de WhatsApp, lo entrega al cliente, y pushea el estado de entrega y respuestas entrantes de vuelta a tu URL de webhook registrada. Nunca tocas un servidor. La autenticación es un access token permanente más firmas de payload HMAC-SHA256. El media está alojado en el CDN de Meta con retención de 90 días.
WhatsApp On-Premise API (self-hosted, deprecada)
Tú — o tu BSP — ejecutas dos imágenes Docker publicadas por Meta (whatsapp/coreapp y whatsapp/web) en tu propia infraestructura. El coreapp se conecta outbound al relay de Meta, cachea mensajes en una base de datos MySQL, y expone una REST API en el puerto 443. Tu equipo maneja certificate rotation, replicación de MySQL, almacenamiento de media, backups, y cada security patch que Meta libera. La especificación mínima de hardware era 4 vCPU y 8 GB RAM por número de teléfono.
Si aún estás en On-Premise: El último security patch se envió el 23 de octubre de 2025. No hay patches futuros planificados. Estás corriendo software con vulnerabilidades conocidas y sin parchear, cero actualizaciones de features, y sin soporte de Meta. La migración no es opcional — está atrasada.
Tabla de comparación completa
Dimensión
Cloud API
On-Premise API
Estado en 2026
Activo — default
EOL 23 oct. 2025
Quién hostea el servidor
Meta
Tú o tu BSP
Footprint de hardware
Ninguno
4 vCPU + 8 GB RAM mínimo por número
Tiempo de setup (via BSP)
Menos de 10 minutos
2–6 semanas (deploy de contenedor + install de cert)
Autenticación
Access token + HMAC-SHA256
Certificado de cliente + admin bearer token
Throughput (default)
80 msg/s por número
30–50 msg/s (limitado por hardware)
Throughput (máximo)
1.000 msg/s bajo solicitud
80 msg/s con multi-node + load balancer
Webhooks entrantes
HTTP POST a tu URL — formato Graph API
HTTP POST a tu URL — formato On-Premise REST
Security patches
Pusheados por Meta automáticamente
Pull-and-deploy manual — ninguno desde oct. 2025
Hosting de media
CDN de Meta, retención de 90 días
Tu almacenamiento, tu política de retención
Nuevas features (Flows, etc.)
Día uno
Backporteadas tarde — o nunca
Costo de infraestructura/mes
$0
$400–$1.200 por número de teléfono
Costo por conversación
Grilla de precios de Meta idéntica
Grilla de precios de Meta idéntica
Unificación Graph API
Sí — superficie compartida con FB + IG
No — superficie REST separada
Residencia de datos
Data centers de Meta (US/EU)
Tu elección
Registro de nuevos números
Abierto
Cerrado desde 15 ene. 2024
El timeline de deprecación
La mayoría de los artículos de comparación pasan por alto las fechas. Estas fechas son toda la historia. Si aún estás en On-Premise, saber exactamente cuándo se cerró cada puerta te dice qué tan urgente es tu situación.
1 de agosto de 2018
Lanzamiento de On-Premise API
WhatsApp Business API se lanza exclusivamente con On-Premise. Se requieren contenedores Docker self-hosted. Comienza la historia enterprise de WhatsApp.
19 de mayo de 2022
Cloud API alcanza general availability
Anunciado en F8 2022. Cloud API se vuelve disponible para todos los negocios. Meta recomienda inmediatamente Cloud como el path de integración preferido para todos los nuevos números.
27 de octubre de 2023
On-Premise API oficialmente deprecada Deprecated
Meta publica el notice de deprecación. Fecha de end-of-life establecida para el 23 de octubre de 2025. El reloj comienza. Cada operador On-Premise es puesto en un timeline de migración obligatorio.
15 de enero de 2024
Cierre de registros de nuevos números en On-Premise
Meta deja de aceptar nuevos números de WhatsApp Business en el stack On-Premise. Todos los nuevos números deben usar Cloud API. Los números On-Premise existentes pueden seguir operando — temporalmente.
23 de octubre de 2025
End-of-life oficial — último security patch End of Life
Se envió el security patch final. Los contenedores On-Premise son ahora software no soportado. Sin patches futuros, sin bug fixes, sin backports de features. Cualquier operador On-Premise que aún corra en 2026 está corriendo sobre una codebase congelada y sin parchear.
2026 y más allá
Cloud API — el único path soportado Activo
Cloud API es la única integración de WhatsApp Business API soportada. WhatsApp Flows, Calling API (lanzada en julio de 2025), nuevos tipos de mensajes interactivos — todos llegan primero a Cloud, y exclusivamente a Cloud de ahora en adelante.
Throughput y rate limits: los números que realmente importan
Los tiers de mensajería diaria son idénticos entre Cloud y On-Premise — están definidos por el sistema de quality scoring de números de teléfono de Meta, no por qué API usas. Ambas APIs comparten los mismos cuatro tiers:
Tier 1: 1.000 clientes únicos iniciados por el negocio por 24 horas (default para todos los nuevos números)
Tier 2: 10.000 clientes únicos por 24 horas
Tier 3: 100.000 clientes únicos por 24 horas
Tier 4: Ilimitado por 24 horas
Los session messages (respuestas dentro de una ventana de 24 horas abierta por el cliente) no tienen cap diario en ningún tier. Donde la Cloud API supera dramáticamente a On-Premise es en el throughput por segundo:
Cloud API
1.000 msg/s
por número de teléfono (bajo solicitud)
80 msg/s out of the box. Escalable a 1.000 msg/s bajo solicitud para senders de alto volumen. Meta absorbe la carga — no se requieren cambios de infra de tu lado.
On-Premise API
30–50 msg/s
límite práctico (single node)
El cap de 80 msg/s aplica en teoría, pero Docker single-node en una VM de 4 vCPU típicamente satura a 30–50 msg/s. Alcanzar 80 msg/s requiere una réplica de MySQL, setup multi-node, y un load balancer.
Para una campaña de Black Friday enviando 100.000 mensajes en una ventana de una hora, la Cloud API absorbe la carga sin configuración. On-Premise requiere trabajo de engineering por adelantado — deploy multi-node, replicación de MySQL, load balancer frente al coreapp — y aún así golpea un techo rígido que la Cloud API elimina completamente.
Lo que realmente pagas
La pricing por conversación de Meta es idéntica para ambas APIs. La diferencia está enteramente en los costos fijos de infraestructura. La mayoría de los artículos de comparación omiten esta parte porque es poco halagadora para los BSPs que aún corren stacks On-Premise.
Cloud API — costo mensual por número
Server hosting$0
Base de datos (MySQL)$0
Gestión de certificados$0
Security patching / DevOps$0
Almacenamiento de media$0 (CDN de Meta)
Tarifas de conversación de MetaPor volumen
Overhead fijo de infra$0 / mes
On-Premise API — costo mensual por número
Server hosting (4 vCPU / 8 GB)$150–$400
MySQL (replicado)$80–$200
Gestión de certificados TLS$20–$60
Engineering on-call$150–$400
Almacenamiento de media / CDN$30–$140
Tarifas de conversación de MetaPor volumen
Overhead fijo de infra$430–$1.200 / mes
Estos costos de infraestructura aplican por número de teléfono. Una agencia gestionando 10 números de WhatsApp de clientes en On-Premise estaba quemando $4.300–$12.000/mes antes de pagarle a Meta una sola tarifa de conversación. La Cloud API elimina ese ítem completo.
La pieza que todo artículo de comparación omite: webhooks entrantes en la Cloud API
Cada artículo sobre Cloud API vs. On-Premise se enfoca en outbound — enviar campañas, templates, broadcasts. Casi ninguno explica qué pasa con los mensajes entrantes en la Cloud API, y aquí es donde la mayoría de los equipos encuentran problemas después de migrar.
Cuando un cliente envía un mensaje a tu número de WhatsApp Business conectado vía la Cloud API, la infraestructura de Meta dispara una solicitud HTTP POST a tu URL de webhook registrada. Esto ocurre en milisegundos. El payload es un objeto JSON estructurado en el formato Graph API de Meta. Tu servidor — o una plataforma de webhook — debe:
Estar públicamente accesible sobre HTTPS en todo momento
Ser capaz de responder con HTTP 200 dentro de 20 segundos (de lo contrario Meta reintenta)
Verificar la firma HMAC-SHA256 en el header X-Hub-Signature-256 antes de procesar
Parsear el formato de payload Graph API — que es diferente del formato REST de On-Premise
Así se ve un payload de mensaje entrante de Cloud API cuando se normaliza a través de la integración de webhook de WhatsApp de SocialHook — entregado a tu endpoint en un formato consistente independientemente del tipo de mensaje:
{ "platform":"whatsapp", "event":"message.received", "timestamp":1747123456, "from":"+44 7700 900 123", "conversation_id":"conv_4m9x...", "message": { "type":"text", "body":"Acabo de migrar a la Cloud API. ¿Cuándo empieza el onboarding?", "id":"wamid.HBgL..." }, "delivery": { "status":"delivered", "latency_ms":38 } }
El rol de SocialHook en un stack de Cloud API: La Cloud API de Meta entrega eventos entrantes a un único endpoint. SocialHook se sitúa entre Meta y tu servidor — manejando verificación de webhook (HMAC-SHA256), normalizando el formato de payload Graph API, agregando retry automático 3x con backoff exponencial si tu servidor retorna un non-200, y loggeando cada entrega con historial completo de estado. Tu servidor recibe un evento JSON limpio y consistente. No importa si el mensaje vino de WhatsApp, Facebook Messenger, o Instagram DMs — el formato de payload es idéntico en los tres. Un endpoint. Tres canales. Flat $50/mes.
Qué cambia realmente cuando migras de On-Premise a Cloud API
Migrar tu número de teléfono de On-Premise a Cloud API está soportado y preserva tu número — los clientes no notan ningún cambio. Pero tu código server-side necesita updates en tres lugares específicos que la mayoría de las guías de migración entierran en notas al pie.
1
Método de autenticación Breaking change
On-Premise usaba certificados TLS de cliente y un admin bearer token. Cloud API usa un access token permanente para outbound y HMAC-SHA256 para verificación de payload entrante. Necesitas actualizar tus auth headers e implementar el check de verificación de firma en tu webhook handler antes de salir a producción.
2
Estructura de payload entrante Breaking change
La REST API de On-Premise y la Graph API de Cloud API usan estructuras JSON diferentes para eventos de webhook entrante. Los nombres de campos, nesting, y metadata difieren. Tu payload parser necesitará un rewrite completo — o usas una capa de normalización como SocialHook que abstrae esto completamente de tu código de aplicación.
3
Lógica de descarga de media
On-Premise almacenaba media entrante en tu servidor. Cloud API almacena media en el CDN de Meta con una política de retención de 90 días. Cuando un cliente envía una imagen o documento, tu payload de webhook contiene un media ID. Debes llamar a la Cloud API para recuperar la URL de descarga, luego fetchear el archivo. El código existente que lee desde un path local se romperá.
4
Endpoint de API outbound
On-Premise exponía una REST API en el puerto 443 de tu contenedor. Cloud API usa el endpoint Meta Graph API en graph.facebook.com. El formato de request, el header de autenticación, y la estructura de URL difieren todos. Actualiza tu configuración de HTTP client y request bodies en consecuencia.
5
Apagar infraestructura
Después de migración y validación, decomisiona tus contenedores Docker, instancia de MySQL, y monitoring asociado. Aquí es donde recuperas los $400–$1.200/mes. Verifica que ningún código de aplicación aún apunte al old local endpoint antes de decomisionar.
¿Es On-Premise alguna vez la respuesta correcta en 2026?
Leemos cada argumento para mantener On-Premise en 2026. Aquí está el análisis honesto:
Requisitos de residencia de datos
El argumento histórico más fuerte para On-Premise era la soberanía de datos — mantener metadata de mensajes dentro de tu propia VPC, en una jurisdicción específica. Cloud API envía datos a través de la infraestructura de Meta (data centers en US y EU). Para empresas bajo ciertas regulaciones gubernamentales o financieras, esta era una constraint genuina. En 2026, la mayoría de estos escenarios se resuelven a través de los settings de residencia de datos EU GDPR-compliant de Meta, o a través de los tiers Enterprise API de Meta con Data Processing Agreements explícitos. El argumento de residencia de datos rara vez sobrevive una legal review hoy — y no sobrevive el argumento de seguridad de correr software sin parchear.
Stacks legacy de BSP
Algunos BSPs no han terminado de migrar toda su flota On-Premise a Cloud API. Si tu stack de WhatsApp es gestionado por un BSP y no te han movido aún, presiónalos. Fuerte. Están operando software no soportado en tu nombre. Cualquier incidente de seguridad en su stack On-Premise post-octubre 2025 es su liability — y potencialmente tuya.
El veredicto
No hay escenario de new-build en 2026 donde On-Premise sea la elección correcta. Para deployments On-Premise existentes con constraints de residencia de datos — consulta a tu equipo legal sobre los términos DPA de Meta y opciones de data center EU, luego migra tan rápido como esa review lo permita. Correr software sin parchear no es una postura de compliance válida para ninguna industria regulada.
Si estás construyendo una nueva integración de WhatsApp hoy: Empieza con la Cloud API. Usa un BSP o plataforma de webhook para el setup. Registra tu número de teléfono, configura tu webhook endpoint, y haz fluir tu primer mensaje entrante a tu servidor. El proceso completo — incluyendo conectar a SocialHook para que tu webhook reciba JSON limpio — toma menos de 15 minutos. Consulta la guía de quickstart.
FAQ
Preguntas frecuentes
¿Sigue soportada la WhatsApp On-Premise API en 2026?
No. Meta la deprecó oficialmente el 27 de octubre de 2023, y la fecha final de end-of-life fue el 23 de octubre de 2025. No se han enviado security patches desde esa fecha, no se pueden registrar nuevos números de teléfono en On-Premise (eso cerró el 15 de enero de 2024), y ninguna nueva feature será backporteadas nunca. Cualquiera que aún corra un contenedor self-hosted en 2026 está en software no soportado y sin parchear.
¿Qué es la WhatsApp Cloud API y cómo difiere de On-Premise?
La WhatsApp Cloud API es la versión hosteada por Meta de la WhatsApp Business Platform. Llamas a graph.facebook.com para enviar mensajes — Meta corre toda la infraestructura. On-Premise requería que corrieras contenedores Docker en tus propios servidores, manejaras MySQL, rotaras certificados TLS, y enviaras security patches tú mismo. Cloud API elimina todo ese overhead operacional.
¿Cuáles son los límites de throughput en la WhatsApp Cloud API?
Cloud API soporta 80 mensajes por segundo por número de teléfono por default, escalable a 1.000 mensajes por segundo bajo solicitud para senders de alto volumen. Los tiers de mensajería diaria (1K / 10K / 100K / ilimitado clientes únicos por 24h) son idénticos entre Cloud y On-Premise — están controlados por el sistema de quality scoring de Meta, no por la versión de API.
¿Necesito mi propio servidor para recibir mensajes entrantes de WhatsApp en la Cloud API?
Sí — o necesitas una plataforma de webhook. Cuando un cliente envía un mensaje a tu número, Cloud API dispara un HTTP POST a tu URL de webhook registrada. Necesitas un servidor públicamente accesible (o un servicio como SocialHook) para recibir, verificar la firma HMAC-SHA256, y procesar el payload. Sin un webhook endpoint funcional, los mensajes entrantes nunca te llegan programáticamente.
¿Cómo se compara la pricing de Cloud API con la pricing de On-Premise?
La pricing por conversación de Meta es idéntica para ambas. La diferencia real es el costo fijo de infraestructura. On-Premise requería $400–$1.200/mes por número de teléfono en hosting, MySQL, monitoring, y engineering. Cloud API tiene $0 de costo de infraestructura — Meta lo absorbe completamente. El total cost of ownership en Cloud API es típicamente 30–60% más bajo que On-Premise al mismo volumen de mensajes.
¿Qué cambia en mi servidor cuando migro de On-Premise a Cloud API?
Tres breaking changes: (1) Autenticación — On-Premise usaba certificados de cliente; Cloud API usa un access token y verificación de firma HMAC-SHA256. (2) Estructura de payload — Cloud API usa el formato JSON Graph API, que difiere de la estructura REST de On-Premise. (3) Manejo de media — On-Premise almacenaba media en tu servidor; Cloud API lo almacena en el CDN de Meta, requiriendo una llamada a API para recuperar URLs de descarga. Tu webhook handler, payload parser, y lógica de media todos necesitan actualización.
Conecta tu número de WhatsApp Cloud API a SocialHook y recibe cada mensaje entrante entregado a tu servidor como JSON limpio — verificado, normalizado, reintentado en fallo — en menos de 50ms. Sin infra. Sin Docker. Sin rotación de on-call.
