Cómo configurar WhatsApp Business API paso a paso

Configurar WhatsApp Business API implica preparar el número, autorizar los activos empresariales, crear credenciales y comprobar el recorrido de un mensaje. Para un equipo técnico u operativo, la prueba útil empieza en el servidor y termina con resultados que pueden relacionarse con el sistema de negocio.

Ruta de este ejemplo: modo API de EngageLab, un número nuevo que cumpla los requisitos del servicio, una plantilla aprobada y un destinatario de prueba autorizado. La coexistencia con Business App y la migración desde otro proveedor requieren sus propios procesos.

Elegir la vía de acceso y comprobar el número

Antes del alta, hay que decidir quién mantiene la conexión. La plataforma permite acceso directo o mediante un proveedor; esa elección determina las credenciales, las herramientas y el reparto de tareas.

Los siguientes pasos utilizan WhatsApp Business API de EngageLab . Si el número ya funciona en Business App o está conectado a otra API, conviene revisar primero qué número utilizar y cómo conectarlo . Una integración mediante un conector de CRM es otra decisión: no sustituye la elección de la vía de acceso ni resuelve por sí sola el alta del número.

Qué preparar antes de configurar la cuenta

La verificación de la empresa y la del número son comprobaciones distintas. Hay que completar las condiciones que Meta y el proceso de alta indiquen para las funciones utilizadas, sin confundirlas con una insignia de cuenta. También debe cumplirse la política de mensajería de WhatsApp : una plantilla aprobada no reemplaza la autorización del destinatario.

Configurar WhatsApp Business API con EngageLab en seis pasos

1. Vincular la cuenta de WhatsApp Business

En EngageLab, abrir el servicio de WhatsApp y elegir el modo API. El proceso redirige al registro de Meta para iniciar sesión, revisar los permisos y crear o seleccionar los activos empresariales correspondientes. La guía de acceso oficial describe esta ruta.

Es posible reutilizar activos disponibles cuando el proceso lo permita. Lo decisivo es seleccionar la empresa y la cuenta de WhatsApp Business correctas, en lugar de crear otra cuenta por defecto.

Comprobación: el alta queda asociada a los activos previstos. Vincularlos todavía no demuestra que el número esté activado para enviar.

2. Registrar y comprobar el número de envío

Añadir el número nuevo en el proceso de registro y completar la verificación disponible. Al volver a EngageLab, continuar con la activación del número de envío indicada por la plataforma y comprobar el estado Connected .

Recibir un código acredita una comprobación de control del número; hay que terminar también los pasos de activación. Si el número ya está en una aplicación o con otro proveedor, corresponde salir de esta ruta y evaluar el caso específico, sin eliminar cuentas como primera medida.

Comprobación: aparece conectado el número correcto. Si sigue pendiente, revisar el activo seleccionado y el paso incompleto antes de repetir solicitudes de verificación.

3. Crear las credenciales para la API

En Claves API , crear una clave y revisar su caducidad, los permisos de envío, los números autorizados y la configuración de IP aplicable. La documentación de claves API explica dónde obtener DevKey y DevSecret.

Estas credenciales se guardan en el servidor. En el ejemplo se leen desde variables de entorno, sin incluir valores reales en el código. No deben exponerse en el navegador, capturas o registros compartidos.

Comprobación: el equipo dispone de una clave habilitada para el número elegido. Su validez se comprobará con la llamada del paso seis; un token de Meta no sustituye estas credenciales.

4. Preparar una plantilla y su idioma

En Plantillas de Mensaje , crear o seleccionar una plantilla adecuada al caso de uso. Las categorías son Marketing, Utility y Authentication. Para esta prueba se prepara una notificación de un pedido, cuyo contenido debe corresponder a ese uso; los códigos OTP pertenecen a Authentication.

El ejemplo presupone un cuerpo como Su pedido {{1}} se ha enviado. , con una sola variable y sin cabeceras ni botones que requieran parámetros adicionales. Su aprobación y clasificación dependen de Meta. La llamada solo debe utilizar una plantilla disponible, con el estado Active documentado por EngageLab.

Comprobación: nombre, idioma y parámetros coinciden con la plantilla aprobada. El código de idioma se toma de esa plantilla, no se deduce del idioma de esta página. Los detalles de creación y aprobación se amplían en plantillas de WhatsApp Business .

5. Configurar los mensajes entrantes y los estados

Preparar una dirección HTTPS de prueba accesible para el proveedor y abrir Configuración de callback . Indicar la dirección y seleccionar los eventos de estado y respuesta necesarios, según la configuración oficial de callbacks .

Un estado informa sobre el mensaje enviado; una respuesta contiene actividad del cliente. El receptor debe distinguir ambos, admitir los registros agrupados en rows y conservar los campos necesarios para relacionarlos con el negocio.

Comprobación: dirección y eventos siguen guardados al revisar la configuración. El paso siguiente comprueba que llegan los eventos reales de la prueba; el diseño de recepción y sus condiciones se consultan en la documentación de callbacks .

6. Enviar una prueba desde el servidor y comprobar la función

Con los requisitos anteriores cumplidos, realizar una llamada al endpoint de envío de EngageLab . Este utiliza HTTP Basic Authentication con DevKey y DevSecret. El siguiente ejemplo usa un solo destinatario:

• Definir en el servidor ENGAGELAB_DEV_KEY y ENGAGELAB_DEV_SECRET .
• Sustituir los marcadores del número empresarial y destinatario por los números correctos, con prefijo internacional.
• Reemplazar nombre e idioma por los de la plantilla aprobada de una variable preparada en el paso cuatro.

Solicitud de ejemplo:

curl --request POST 'https://wa.api.engagelab.cc/v1/messages' \
  --user "${ENGAGELAB_DEV_KEY}:${ENGAGELAB_DEV_SECRET}" \
  --header 'Content-Type: application/json' \
  --data '{
  "from": "<NUMERO_EMPRESA>",
  "to": [
    "<DESTINATARIO_AUTORIZADO>"
  ],
  "body": {
    "type": "template",
    "template": {
      "name": "<PLANTILLA_APROBADA>",
      "language": "<IDIOMA_DE_LA_PLANTILLA>",
      "components": [
        {
          "type": "body",
          "parameters": [
            {
              "type": "text",
              "text": "PED-001"
            }
          ]
        }
      ]
    }
  },
  "request_id": "prueba-pedido-001-intento-1",
  "custom_args": {
    "order_id": "PED-001",
    "attempt_id": "ENV-001"
  }
}'

El pedido PED-001 aparece en el texto y en los datos de correlación. ENV-001 identifica este intento en el sistema empresarial. Son valores de ejemplo, no registros de un cliente.

Respuesta síncrona ilustrativa:

{
  "message_id": "<MESSAGE_ID_DEVUELTO>",
  "request_id": "prueba-pedido-001-intento-1"
}

Guardar el message_id realmente devuelto y el resultado HTTP. request_id permite reconocer la petición; no debe interpretarse como una garantía de envío idempotente. Esta respuesta confirma la aceptación de la petición, todavía no la entrega al destinatario.

Fragmento ilustrativo del callback de entrega:

{
  "total": 1,
  "rows": [
    {
      "message_id": "<MESSAGE_ID_DEVUELTO>",
      "server": "whatsapp",
      "channel": "whatsapp",
      "itime": 1700000000,
      "custom_args": {
        "order_id": "PED-001",
        "attempt_id": "ENV-001"
      },
      "status": {
        "message_status": "delivered"
      }
    }
  ]
}

El marcador de mensaje corresponde al mismo identificador de la respuesta. La fecha numérica es ilustrativa y se han omitido otros campos del evento. custom_args permite recuperar la asociación de esta notificación en el callback de estado, dentro del alcance documentado.

Comprobación funcional: la llamada del servidor se acepta, el estado de entrega se asocia al pedido y una respuesta del destinatario autorizado entra por la rama de mensajes entrantes. Una prueba desde la consola, por sí sola, no comprueba las credenciales del servidor. La ausencia de read tampoco demuestra por sí sola un fallo de envío.

Vincular la prueba con el CRM o sistema propio

La API informa sobre mensajes; el sistema empresarial mantiene el contexto del pedido. La asociación puede residir en un CRM, un sistema de pedidos o una base de datos de integración.

Un mismo mensaje puede pasar por sent , delivered y read . Por eso, descartar todo evento cuyo message_id ya exista eliminaría actualizaciones legítimas. Conviene conservar los eventos y diseñar la detección de duplicados con los campos disponibles, distinguiendo estado, contenido y tiempo.

Los mensajes del cliente se procesan por separado en response . Su asociación debe usar el identificador de contacto y el contexto de respuesta disponible; no hay que suponer que cualquier mensaje entrante incluye el pedido o devuelve todos los datos de custom_args .

Resolver incidencias y preparar la operación en producción

La prueba anterior confirma un recorrido normal. Para operar el canal hace falta saber cómo detectar fallos, quién los atiende y qué ocurre cuando faltan eventos.

La especificación del receptor pide responder con HTTP 200, sin cuerpo, en un plazo de tres segundos. La recepción debe ajustarse a ese contrato; una opción de diseño es conservar el evento y separar las tareas pesadas. Un 200 no acredita que el CRM ya se haya actualizado.

Un timeout de la llamada no justifica reenviar sin revisar qué ocurrió: el sistema debe tratar la incertidumbre y el riesgo de duplicación. Estas comprobaciones de producción se realizan aparte de la prueba funcional y no se sustituyen con una captura de un mensaje recibido.

Qué costes y condiciones conviene confirmar

El presupuesto debe separar tarifas de Meta, cargos del proveedor, posibles conectores o puestos de trabajo y mantenimiento de la integración. Para consultar los precios de WhatsApp Business API , conviene preparar mercados de destino, categorías de mensaje y volumen previsto.

La ventana de atención dura 24 horas y se abre o reinicia con cada mensaje del usuario. Permite responder sin plantilla dentro de ese periodo; fuera de él se necesitan plantillas aprobadas. Esa regla de envío no determina por sí sola el coste.

Las FAQ oficiales de WhatsApp recogen desde el 1 de octubre de 2026 el cobro por mensajes de servicio, con los primeros 1.000 mensuales gratuitos por número empresarial. El cálculo debe contrastarse con las tarifas y condiciones vigentes, sin presuponer que toda respuesta dentro de la ventana de atención es gratuita.

Antes de contratar, también interesa concretar quién administra los activos, qué registros estarán disponibles y cómo se escalan las incidencias.

Preguntas frecuentes

¿Hace falta un BSP para configurar WhatsApp Business API?

No. Existe acceso directo a Meta y acceso mediante proveedores. La elección depende de quién va a desarrollar, mantener y gestionar la conexión. El ejemplo de esta guía utiliza EngageLab.

¿Se puede mantener el número de WhatsApp Business App?

Puede ser posible mediante una ruta de coexistencia compatible. Requiere comprobar sus condiciones y seguir ese proceso específico; no equivale al alta de un número nuevo utilizada aquí.

¿Se puede probar la configuración antes de pasar a producción?

Sí. Una prueba controlada permite comprobar envío, eventos y respuesta. Sus requisitos dependen del entorno y la cuenta; la prueba no sustituye la revisión de seguridad, recuperación y operación.

¿Es obligatorio conectar un CRM?

No. La asociación puede mantenerse en un sistema propio o servicio de integración. Lo necesario para este caso es conservar el vínculo entre pedido, intento, mensaje y eventos posteriores.