Meta partió la WABA en dos: qué cambia en la API de WhatsApp

Si administras un número de WhatsApp Business Platform, en las últimas semanas te apareció este aviso en Meta Business Suite: «Updates to your account». Al cerrarlo, la vista de la WABA ya no es una sola. Ahora hay dos pestañas, WhatsApp accounts y Messaging accounts.

Meta cambió el modelo de datos de la plataforma sobre la que trabajan todos los proveedores. La migración fue automática y terminó a mediados de octubre de 2026. Ningún ID cambió y ninguna integración se rompió. Lo que sí cambió es quién es dueño de qué: el número queda siempre en manos del negocio, y las plantillas y la facturación pasan a una cuenta aparte por cada proveedor.

El problema que había

Hasta ahora, la WhatsApp Business Account (WABA) agrupaba todo en una sola entidad: los números, las plantillas, el medio de pago, las suscripciones a webhooks y el acceso de los proveedores. En la práctica, un número solo podía estar con un proveedor.

Si una empresa quería usar un proveedor para difusiones y otro para atención, necesitaba dos números, y su cliente los veía como dos contactos distintos en su lista de chats. Cambiar de proveedor implicaba migrar el número, un trámite que la propia Meta describe ahora como «una barrera natural para cambiar».

Meta había probado una solución intermedia, Multi-Solution Conversations, en beta cerrada y con requisitos altos. El modelo nuevo la reemplaza y la abre a todos.

El modelo nuevo: dos cuentas

La WABA se dividió en dos contenedores con responsabilidades separadas.

WhatsApp account (WAAC). Es la identidad del negocio, lo que ve el usuario en WhatsApp. Contiene:

• un único número de teléfono (más adelante, también un nombre de usuario),
• el perfil del negocio,
• los catálogos de productos.

La WAAC siempre es del negocio, nunca del proveedor, y se comparte con los proveedores que el negocio elija. Como cada una tiene un solo número, varias WAAC se pueden agrupar en una jerarquía, con una principal y otras vinculadas, que Meta llama «phone set».

Messaging account (cuenta de mensajería). Es la operación de un proveedor sobre ese número. Contiene:

• las plantillas,
• el medio de pago,
• las suscripciones a webhooks.

Puede ser del negocio o del proveedor, y cada proveedor tiene la suya. Un número puede tener varias cuentas de mensajería asociadas.

Si integras con la API, ten en cuenta que los IDs de WABA que ya existían ahora identifican cuentas de mensajería. El waba_id que tienes guardado sigue sirviendo, pero apunta a la mitad operativa, no al número.

Lo que no cambió

Siguen igual:

• los endpoints de la Cloud API, con las mismas rutas y los mismos payloads (POST /<PHONE_NUMBER_ID>/messages),
• los IDs de número de teléfono y los tokens de acceso,
• el flujo de plantillas: crear, editar y mandar a revisión,
• la suscripción a webhooks, que se sigue haciendo al topic whatsapp_business_account con el ID de la cuenta de mensajería,
• el precio por mensaje.

Si tu integración funcionaba el 22 de septiembre, funciona hoy.

Lo que se comparte entre proveedores

La facturación se separa, pero tres cosas siguen siendo del número y se reparten entre todos los proveedores conectados:

• Calidad. Vive en la WAAC. Si un proveedor manda difusiones que los usuarios bloquean o reportan, la calidad baja para todos.
• Límite de mensajes. Se calcula a nivel de business portfolio y cuenta usuarios únicos en 24 horas. Sumar un segundo proveedor no lo duplica.
• Throughput. Sigue siendo del número. Dos proveedores mandando a la vez se reparten los mensajes por segundo.

Con las sanciones, Meta separaba según el origen. En el esquema anterior, una violación de plantillas se aplicaba solo a la cuenta que la cometía, y una del número o del portfolio, a todas. La documentación nueva no dice si eso se mantiene. Si se mantiene, una plantilla rechazada afecta solo al proveedor que la creó, y un número bloqueado deja sin servicio a todos.

Quién recibe los mensajes entrantes

Si operas un bot, necesitas saber a quién le llega lo que escribe el cliente, y la documentación del modelo nuevo no lo dice. Explica que los webhooks se suscriben por cuenta de mensajería y que los recibos de entrega (sent, delivered, read) vuelven a la app que mandó el mensaje, pero no menciona los mensajes entrantes.

El antecedente es Multi-Solution Conversations, el esquema que el modelo nuevo reemplaza. Ahí Meta decía explícitamente que todos los proveedores con acceso al número reciben todos los webhooks entrantes, y que el negocio coordina quién contesta. Si eso se mantiene, dos bots conectados al mismo número van a responderle al mismo cliente si nadie define los turnos.

Antes de conectar un segundo proveedor, define quién atiende las consultas, quién manda difusiones y quién no contesta nunca.

Facturación: el token decide quién paga

Cada cuenta de mensajería tiene su propio medio de pago, independiente del resto. Cada mensaje se cobra a la cuenta de mensajería del que lo envía, y Meta la resuelve a partir del token de acceso:

• Si el token puede enviar desde una sola cuenta de mensajería en ese número, Meta la elige sola. Es el caso típico de un proveedor con un cliente.
• Si puede enviar desde más de una, hay que indicarla con un parámetro nuevo, messaging_account_id:

curl -X POST 'https://graph.facebook.com/v22.0/<PHONE_NUMBER_ID>/messages' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{
    "messaging_product": "whatsapp",
    "to": "<USER_PHONE>",
    "messaging_account_id": "<MESSAGING_ACCOUNT_ID>",
    "type": "template",
    "template": { "name": "<TEMPLATE_NAME>", "language": { "code": "es" } }
  }'

Un token llega a más de una cuenta cuando una empresa con integración propia suma un proveedor para un caso puntual, cuando un cliente le comparte varias cuentas al mismo proveedor, o cuando factura en varias monedas, porque cada moneda necesita su propia cuenta de mensajería.

Si hay ambigüedad y omites el parámetro, Meta no garantiza el resultado: el mensaje puede cobrarse a la cuenta equivocada o ser rechazado. Y si usabas paid_messaging_account_id, el nombre anterior, tienes hasta el 31 de diciembre de 2026 para pasarte al nuevo.

Para saber si una cuenta de mensajería tiene medio de pago:

curl 'https://graph.facebook.com/v22.0/<MESSAGING_ACCOUNT_ID>?fields=primary_funding_id' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>'

Si no devuelve primary_funding_id, esa cuenta no puede enviar mensajes pagos.

Las plantillas no viajan solas

Las plantillas pertenecen a la cuenta de mensajería donde se crearon y no se comparten. Si un negocio cambia de proveedor, o suma uno, sus plantillas aprobadas no aparecen en la cuenta nueva.

Hay dos caminos: crearlas de nuevo y mandarlas a revisión, o copiarlas con la API de migración:

curl -X POST 'https://graph.facebook.com/v26.0/<DESTINATION_WABA_ID>/migrate_message_templates' \
  -H 'Authorization: Bearer <ACCESS_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{ "source_waba_id": "<SOURCE_WABA_ID>", "page_number": 0 }'

La API solo copia entre cuentas del mismo negocio en Meta, solo copia plantillas aprobadas con calidad verde o sin calificar, y reinicia la calidad y el tier de lo que copia. Meta calcula entre dos y cuatro semanas hasta que esas plantillas vuelven a rendir. Cambiar de proveedor la semana previa a una campaña fuerte es mala idea.

Coexistencia: el caso especial

Muchos negocios usan la app de WhatsApp Business en el celular y la API al mismo tiempo, sobre el mismo número. Eso es la coexistencia, y esos números también migraron al modelo nuevo. Al conectarlos, Meta convierte la WABA que ya existía en una cuenta de mensajería compatible y la comparte con el proveedor, en lugar de crearle una propia.

El calendario

En la fase 3 hay que cambiar el identificador en la ruta de /messages, el endpoint más usado de la plataforma. Meta recomienda planificarlo durante 2027.

Qué significa para Trama y sus clientes

En Trama no llamamos a la Cloud API de WhatsApp directamente: el transporte lo hace nuestro proveedor de mensajería. Los cambios de API de 2027 y 2028 se absorben en esa capa, y para la fase 1 no tuvimos que tocar nada.

Para quien usa Trama, cambian tres cosas:

• El número es tuyo, y ahora Meta lo deja explícito. Ningún proveedor, tampoco nosotros, puede quedárselo.
• Probarnos ya no exige mudar el número. Si trabajas con otro proveedor, puedes conectarnos al mismo número. Define antes quién responde las consultas, para que no le contesten dos sistemas al mismo cliente.
• Otro proveedor en tu número te puede afectar. Si manda mensajes que la gente bloquea, baja la calidad del mismo número que usa Trama para atender tus ventas.

Si te interesa el lado económico, lo explicamos en cuánto cuesta WhatsApp Business API para una agencia de viajes. Y si te preguntas cuántos números conviene tener, en por qué cada vendedor debería tener su propio WhatsApp contamos por qué repartir el riesgo entre varios números es mejor que concentrarlo en uno.

Lo que hay que llevarse

• La WABA se partió en una WhatsApp account, que es el número y siempre es del negocio, y una cuenta de mensajería por proveedor, con las plantillas, el pago y los webhooks.
• Los IDs de WABA existentes ahora son IDs de cuentas de mensajería.
• Varios proveedores pueden compartir un número, y con él comparten la calidad, el límite diario y el throughput.
• Las plantillas no se comparten entre cuentas de mensajería, y migrarlas reinicia su calidad.
• Antes del 31 de diciembre de 2026, pásate a messaging_account_id. Durante 2027, prepara el cambio del ID del número por el de la WAAC para 2028.