Cómo saber si tu WhatsApp usa la API oficial

Casi todas las plataformas de mensajería masiva dicen operar sobre la API oficial de WhatsApp. Algunas dicen la verdad, otras conectan un teléfono real con automatización por encima, y unas cuantas están en un punto intermedio que nadie te explica: son oficiales, sí, pero el número no está a tu nombre.

La distinción no es académica. Determina si te pueden suspender, si te puedes llevar el número cuando cambies de proveedor, y de quién es el historial de conversaciones.

Las tres cosas que suelen venderse como "la API"

Un teléfono con automatización encima. Alguien conecta un WhatsApp normal —o el WhatsApp Business de la tienda de aplicaciones— a un software que lee y responde. Funciona, es barato, y es el que Meta suspende. Se reconoce porque el alta pide escanear un código QR.

La API oficial con el número a nombre del proveedor. Es la API de verdad, pero la cuenta la posee la empresa que te la vendió. Puedes operar sin problemas durante años y descubrir el detalle el día que quieras irte.

La API oficial con la cuenta a tu nombre. El portfolio de negocio es tuyo, la cuenta de WhatsApp es tuya, y quien la opera tiene acceso concedido por ti. Es la única de las tres donde el activo es tuyo.

Si el alta te pidió un código QR, no es la API. Si nunca viste el panel de WhatsApp Manager con tu empresa como titular, probablemente sea la segunda.

La comprobación que no falla

Pide entrar al portfolio de negocio de Meta y busca la sección de cuentas de WhatsApp. Ahí aparece quién es el propietario. Si figura el nombre de tu proveedor, ya tienes la respuesta.

Después mira el número. En la API oficial no existe la aplicación de WhatsApp en un celular: los mensajes viven en el sistema que la consume. Si alguien de tu equipo todavía abre los chats desde un teléfono, hay coexistencia configurada o directamente no es la API.

El error que nos costó una sesión entera

Hay un fallo mucho más caro que la pregunta del titular, y solo aparece cuando el CRM y el proveedor de mensajería no son la misma empresa.

En una sub-cuenta teníamos dos aplicaciones instaladas. Los mensajes que entraban quedaban atribuidos a una, y las respuestas salían por la otra — que intentaba enviarlas desde el número de otro cliente.

La secuencia quedó registrada al segundo:

18:36:28  el CRM marca el mensaje como enviado
18:36:30  lo recibe el puente equivocado
18:36:31  Meta lo rechaza: 131047, re-engagement message

Lo que impidió que ese mensaje saliera desde el número de otra empresa no fue una protección nuestra: fue que Meta lo rechazó por un motivo distinto. Con la ventana de conversación abierta, habría salido.

El síntoma, visto desde afuera, es "no salen los mensajes", y apunta directo al sistema propio. El sistema propio estaba sano: un envío forzado con el proveedor correcto recorrió la cadena entera y devolvió su identificador de mensaje sin queja. Se puede perder una tarde depurando código que funciona.

La comprobación que separa un caso del otro es comparar el identificador del proveedor en el mensaje que entra contra el del mensaje que sale. Si difieren, el problema es de instalación de aplicaciones, no de código, y se arregla desinstalando la que sobra.

"Enviado" no significa entregado

El otro hallazgo del mes va en la misma dirección. Al mandarle el enlace de una reunión a un prospecto, la llamada respondió success: true con estado sent. Un segundo después, releyendo el mensaje por su identificador, el estado era failed con un error de suscripción inactiva.

Sin esa relectura, el reporte habría sido "ya le escribí por WhatsApp" con el prospecto esperando algo que nunca llegó.

La causa: esa cuenta no tenía contratado el WhatsApp nativo del CRM, y el tipo de mensaje que usamos apuntaba al producto nativo en lugar de al proveedor conectado. Dos productos con el mismo nombre y comportamientos distintos.

La regla que sacamos de ahí: después de cualquier envío por API, releer el mensaje por su identificador y mirar estado y error. Un sent en la respuesta significa encolado, y nada más.

La lista corta

Si quieres saber en diez minutos qué tienes montado:

1. ¿El alta pidió un QR? Entonces no es la API oficial.
2. ¿Quién figura como propietario de la cuenta en el portfolio de negocio?
3. ¿Tienes acceso de administrador, o solo tu proveedor?
4. Si el CRM y la mensajería son de empresas distintas, compara el proveedor del mensaje entrante contra el del saliente.
5. Después de enviar por API, relee el mensaje. El estado del envío no es el estado de la entrega.

Escribimos aparte por qué un 200 no prueba que tu integración funciona, que es la versión general de este mismo problema. Y si quieres la API oficial montada con la cuenta a tu nombre desde el primer día, así la implementamos.