Cómo configurar WhatsApp Business Calling API

Activar WhatsApp Business Calling API no equivale a lanzar un canal telefónico que funcione. La API puede mostrar un botón de llamada, pero una puesta en marcha real también necesita un número apto en Cloud API, ajustes, señalización, audio, reglas de permiso, horarios, un responsable y un camino probado para cuando nadie contesta.

La forma más segura de empezar es limitar el alcance. Usa un número, recibe primero llamadas del usuario y comprueba que el resultado vuelve al mismo historial que los mensajes. Añade llamadas salientes cuando los permisos y la falta de respuesta estén controlados.

Empieza por comprobar el número y la cuenta

El resumen actual de Meta sobre Calling API indica que el número empresarial debe usar Cloud API y no solo la aplicación WhatsApp Business. La aplicación conectada debe estar suscrita a la WhatsApp Business Account y al campo webhook calls. También necesita el permiso whatsapp_business_messaging.

Las llamadas están desactivadas por defecto. Para habilitarlas en un número de producción, Meta exige además un límite diario de mensajería de al menos 2.000 destinatarios únicos. Los números públicos de prueba y las cuentas sandbox aptas permiten probar la función sin alcanzar ese umbral de producción.

Verifica esas condiciones antes de construir la capa de audio. De lo contrario, el equipo puede depurar WebRTC o SIP cuando el número no es apto. Reúne cuenta, ID del número, aplicación, suscripciones, dueño de permisos y límite actual en una ficha sin tokens.

Decide primero quién puede llamar a quién

La API admite dos caminos distintos. Una llamada iniciada por el usuario comienza cuando una persona llama a la empresa desde WhatsApp. Una llamada iniciada por la empresa comienza cuando el negocio llama al usuario.

Trátalos como dos lanzamientos. El camino entrante prueba recepción, enrutamiento, respuesta y cierre. El saliente añade un sistema de consentimiento. Meta exige permiso del usuario antes de que la empresa lo llame. Puede ser temporal o permanente, y el usuario puede revocarlo.

La guía de permisos de llamada de Meta permite actualmente una solicitud en 24 horas y dos en siete días para cada pareja de empresa y usuario. También aplica restricciones tras varias llamadas salientes no contestadas o rechazadas. Guarda el estado y el origen del permiso. No conviertas el consentimiento para mensajes en permiso de llamada por suposición.

Configura la expectativa antes de mostrar el botón

Un botón visible promete que alguien contestará. Configura esa promesa antes de publicarlo.

La documentación de ajustes de Meta permite activar llamadas, controlar la visibilidad del icono, definir horarios y festivos, habilitar permisos de devolución y configurar buzón de voz. Los horarios usan una zona horaria con nombre, algo importante al atender varios mercados o cambios de horario estacional.

Define qué ocurre cuando el equipo está disponible, lleno, cerrado o temporalmente fuera de servicio. Ofrece una alternativa como escribir, pedir una devolución o dejar un mensaje. Meta advierte que las aplicaciones pueden tardar hasta siete días en reflejar un cambio aunque el servidor ya lo aplique. Compruébalo en dispositivos reales.

Conecta señalización y audio de forma consciente

La arquitectura predeterminada usa Graph API y webhooks para señalización y WebRTC para audio. Meta también documenta SIP para conectar una plataforma de voz existente. Elige pronto porque activar SIP cambia el uso de endpoints y webhooks.

En una llamada WebRTC entrante, el campo calls entrega el evento de conexión y la oferta de sesión. Meta recomienda pre accept para preparar la conexión antes de la aceptación final y reducir retrasos o audio recortado. Después, la llamada pasa por estados explícitos de aceptación, conversación y finalización.

Conserva esos estados en un registro. Incluye ID de llamada, número empresarial, cliente, dirección, permiso cuando corresponda, tiempos, estado final y responsable. Una duración superior a cero no demuestra un resultado correcto.

Prueba todo el camino del cliente

Una respuesta correcta de la API es solo un punto de control. Prueba desde el dispositivo del cliente hasta la persona o el sistema que debe responder.

Empieza con un número público de prueba de Meta o un sandbox apto. Después haz una prueba de producción controlada con un número. Revisa el icono, horarios, conexión entrante, audio en ambos sentidos, tiempo de espera, llamada perdida, permiso de devolución, webhook final y registro visible para el equipo.

Prueba también el fallo. Corta el audio, deja sonar, rechaza la llamada y revoca el permiso saliente. Confirma que los reintentos no crean duplicados ni solicitudes repetidas. Nombra a quien pueda desactivar las llamadas si fallan calidad, privacidad o capacidad.

Mantén la llamada dentro de la conversación

La llamada pierde utilidad si su resultado queda separado. El siguiente agente debe ver que ocurrió, quién la gestionó, cómo terminó y qué necesita el cliente. Una nota breve suele servir más que una duración aislada.

Las páginas actuales de DripTell sobre el canal de WhatsApp y la bandeja compartida describen historial de mensajes, responsabilidad y contexto. Por sí solas no demuestran que WhatsApp Business Calling API esté habilitada en un espacio concreto. Confirma el soporte de llamadas y la arquitectura por separado y decide qué eventos y resultados deben volver al historial.

Lanza un número con un equipo responsable. El botón se ve enseguida. Lo que lo hace útil es un camino de respuesta fiable.

Preguntas frecuentes

Qué se necesita para activar WhatsApp Business Calling API

Necesitas un número apto de WhatsApp Business Platform en Cloud API, suscripciones de aplicación y webhooks, whatsapp_business_messaging, límite suficiente, ajustes activados y un camino funcional de señalización y audio.

Puede una empresa llamar a cualquier usuario de WhatsApp

No. Las llamadas iniciadas por la empresa requieren permiso del usuario y la disponibilidad depende del país del número empresarial. Revisa las restricciones actuales de Meta.

Debe el equipo usar WebRTC o SIP

Usa WebRTC si la aplicación gestionará directamente la señalización de Graph API y el audio. Considera SIP al conectar una plataforma de voz existente. La elección afecta endpoints, webhooks, operación y diagnóstico, así que hazla antes de implementar.

Cómo debe probarse la configuración

Prueba éxito y fallo desde un dispositivo real. Verifica horarios, permisos, conexión, audio bidireccional, llamadas perdidas, eventos finales, propiedad, registros y el camino de desactivación de emergencia.