Ilustración del flujo de trabajo de WA Lookup para «Integración de WA Lookup: higiene automatizada de datos del CRM y clasificación de cuentas»
Una visión general del flujo de trabajo que se analiza en este artículo de WA Lookup.

Aprenda a integrar la API síncrona de WA Lookup para verificar la presencia de cuentas de WhatsApp, obtener detalles del avatar y clasificar cuentas de empresa para la higiene de datos del CRM.

La API de WA Lookup permite a los sistemas CRM realizar una verificación síncrona de la presencia de cuentas de WhatsApp. Al enviar una solicitud POST al endpoint /api/v1/check con un número de teléfono en formato E.164, los desarrolladores pueden obtener el estado de registro, la disponibilidad del avatar o la clasificación de cuenta de empresa en la misma respuesta HTTP. Estos datos ayudan a mantener la higiene del CRM al identificar registros válidos vinculados a WhatsApp sin necesidad de procesamiento asíncrono, sondeo ni webhooks.

Cómo es la arquitectura de la API de WA Lookup

Integrar señales de presencia de cuenta en un CRM requiere una arquitectura que permita enrutar datos y tomar decisiones de inmediato. La API de WA Lookup está diseñada en torno a un único endpoint síncrono: POST /api/v1/check. Cuando un sistema CRM o una plataforma de operaciones de datos envía una solicitud, la API procesa la verificación y entrega los resultados en la misma respuesta HTTP. Esta arquitectura síncrona elimina la carga de ingeniería asociada al procesamiento asíncrono, como configurar webhooks, gestionar URL de devolución de llamada o implementar lógica de sondeo. Los desarrolladores pueden integrar la API directamente en flujos de trabajo síncronos, como formularios de captación de leads o canalizaciones de depuración de datos en tiempo real. Para una verificación de WhatsApp completada, el data devuelto contiene service_type, identifier y registered; ws_avatar incluye además avatar y avatar_url, mientras que ws_business incluye business. No se devuelven campos internos de registro, transacción, estado ni facturación.

Clasificación de los tipos de cuenta de WhatsApp

Para dar respuesta a los distintos requisitos de higiene de datos del CRM, la API en tiempo real ofrece tres tipos de servicio distintos. Los tres utilizan el mismo endpoint síncrono, y el parámetro service_type controla qué campos concretos se devuelven en la respuesta y qué coste de saldo se aplica a la transacción.

Comparación de los tipos de servicio

Tipo de servicio Capacidad principal Campos devueltos
ws Señal de registro en la plataforma registered
ws_avatar Enriquecimiento del perfil y disponibilidad del avatar registered, avatar (booleano), avatar_url (cadena, vacía cuando no hay URL disponible)
ws_business Señal de perfil de empresa registered, business (booleano)

El WhatsApp Checker (ws) es el tipo de servicio fundamental. Se utiliza únicamente para confirmar si un número de teléfono enviado está registrado en WhatsApp y devuelve solo el campo registered. Suele emplearse para la limpieza básica de listas y para identificar qué contactos del CRM tienen cuenta en WhatsApp. El WhatsApp Avatar Checker (ws_avatar) amplía la verificación básica con capacidades de enriquecimiento del perfil. Además del estado de registro, devuelve un booleano avatar que indica si hay una foto de perfil establecida y una cadena avatar_url. El campo de URL está vacío cuando no hay URL disponible. Esta señal puede ayudar a los equipos a revisar el grado de completitud del perfil de un contacto. El WhatsApp Business Checker (ws_business) está diseñado para la segmentación de CRM B2B. Verifica el registro en WhatsApp y devuelve un booleano business que indica si la cuenta utiliza WhatsApp Business. Esto permite a los responsables de operaciones de datos separar las cuentas personales de las cuentas de empresa en sus bases de datos.

Implementación técnica e higiene de datos

Integrar la API en un CRM o en una canalización de datos requiere ajustarse al contrato de solicitud documentado. La API espera una carga JSON y cabeceras concretas para autenticar y procesar correctamente la solicitud. El contrato de solicitud documentado requiere una solicitud POST a /api/v1/check. La solicitud debe incluir dos cabeceras: X-API-Key, que contiene su clave de autenticación, y Content-Type: application/json. El cuerpo JSON debe contener exactamente dos campos:

  1. service_type: un valor de cadena ws, ws_avatar o ws_business.
  2. identifier: el número de teléfono que se va a verificar.

Es fundamental que todos los números de teléfono enviados tengan el formato del plan internacional de numeración telefónica E.164. Por ejemplo, un número de EE. UU. debe enviarse como +17253100591. No utilizar el formato E.164 puede provocar errores de interpretación o verificaciones indeterminadas. Un cuerpo JSON estándar tiene este aspecto: {"service_type": "ws_business", "identifier": "+17253100591"} Al estandarizar las entradas del CRM en E.164 y enviarlas a través de esta verificación síncrona, los desarrolladores pueden marcar automáticamente los números no válidos, segmentar a los usuarios de empresa y mantener un alto nivel de higiene de datos. Como la respuesta es inmediata, estas verificaciones pueden integrarse directamente en los formularios de entrada de datos, lo que garantiza que solo se guarden en la base de datos señales de presencia de cuenta verificadas.

Informes del panel y gestión de la cuenta

La gestión del uso de la API y la supervisión de las operaciones de higiene de datos se realizan desde el panel de la plataforma. El panel ofrece herramientas completas para que los administradores del CRM y los desarrolladores sigan el rendimiento de su integración y gestionen la autenticación. El panel permite una gestión completa de las claves API, de modo que los equipos pueden rotarlas de forma segura. Para la supervisión operativa, ofrece visibilidad del saldo actual de la cuenta, el historial detallado de verificaciones y los informes por producto. Los administradores pueden revisar las verificaciones recientes, supervisar el gasto de saldo y analizar la actividad de la cuenta para entender cómo se utiliza la API en los distintos flujos de trabajo del CRM. Para una verificación de WhatsApp completada, el data devuelto contiene service_type, identifier y registered; ws_avatar incluye además avatar y avatar_url, mientras que ws_business incluye business. No se devuelven campos internos de registro, transacción, estado ni facturación.

Preguntas frecuentes

¿La API de WA Lookup es síncrona o asíncrona?

La API de WA Lookup es estrictamente síncrona. Cuando se envía una solicitud al endpoint POST /api/v1/check, los resultados se devuelven en la misma respuesta HTTP que la solicitud.

¿Puede esta API verificar si un usuario está conectado en este momento?

No. Un resultado registrado informa de los campos de estado de WhatsApp disponibles en el momento de la verificación. Actúa únicamente como una señal de presencia de cuenta y no informa de la presencia en tiempo real, el historial de mensajes, el consentimiento del contacto ni de si actualmente se puede contactar con el número.

¿Cuál es la diferencia entre los tipos de servicio ws, ws_avatar y ws_business?

Los tres tipos de servicio utilizan el mismo endpoint síncrono, pero devuelven campos diferentes. El tipo de servicio ws confirma el registro básico en WhatsApp. El tipo de servicio ws_avatar devuelve el estado de registro junto con un booleano de avatar y un campo de URL del avatar, que está vacío cuando no hay URL disponible. El tipo de servicio ws_business devuelve el estado de registro y un booleano que indica si la cuenta utiliza WhatsApp Business.

Fuentes