WhatsApp multiagente con la API oficial

Actualizado el 25/10/2026

Para tener varios agentes en el mismo número de WhatsApp hay dos caminos: los dispositivos vinculados de la app WhatsApp Business, que tienen un límite de dispositivos, o la API oficial de WhatsApp, en la que el número lo opera un sistema y los agentes trabajan en una bandeja de entrada compartida, sin un límite de personas impuesto por Meta. Con la API, la distribución, el historial y los permisos quedan en tu software. Con la coexistencia, incluso el teléfono puede seguir funcionando en paralelo.

Los límites de la app WhatsApp Business

La app se diseñó para uso manual. Según el Servicio de ayuda de WhatsApp, una cuenta business puede vincular hasta cuatro dispositivos; la función multiagente amplía el límite hasta 10, según los beneficios de suscripciones como Meta Verified. Eso sirve para un negocio pequeño, pero falla cuando el equipo crece:

Todos ven todo. No hay cola ni conversaciones «mías» y «tuyas». Dos agentes responden al mismo cliente, o ninguno.
Sin métricas por persona. No se sabe quién respondió, en cuánto tiempo ni cuántas conversaciones resolvió cada uno.
Dependencia del teléfono principal. Si el dispositivo principal queda sin uso unos 14 días, los dispositivos vinculados se desconectan.
Sin integraciones. La app no se conecta con el CRM, el ERP ni el bot.

Cómo lo resuelve la API: el número se vuelve un sistema

En la API oficial, el número no está en un teléfono. Cada mensaje recibido llega a tu servidor por webhook y cada respuesta sale por una llamada HTTP. El «agente» no es un dispositivo vinculado a WhatsApp, es un usuario de tu sistema. Por eso Meta no limita cuántas personas atienden: el límite lo pone tu software.

Aspecto	App con dispositivos vinculados	API con bandeja compartida
Cantidad de agentes	Hasta 4 dispositivos (hasta 10 con multiagente)	La define tu sistema
Distribución	Manual	Automática, por reglas
Historial	En el dispositivo	En tu base de datos
Métricas por agente	No	Sí, a partir de los eventos
Bot e IA	No nativo	Integrado al mismo flujo
Permisos	Quien tiene el dispositivo ve todo	Por equipo, cola o rol

Arquitectura de una bandeja de entrada compartida

Una atención multiagente con la API tiene cinco piezas:

Receptor de webhook. Recibe los eventos de Meta, responde 200 rápido y pone el evento en una cola. No hagas nada pesado aquí.
Procesador. Lee la cola, guarda mensajes y estados, abre o reabre la conversación y llama al motor de distribución.
Motor de distribución. Decide quién atiende: el bot, la cola de un departamento o un agente específico.
Interfaz del agente. Conversaciones asignadas, historial y campo de respuesta, actualizados en tiempo real (WebSocket o similar).
Envío. Una capa única que llama a la API, guarda el wamid devuelto y trata los errores.

Dos detalles del webhook cambian el diseño. La descripción general de webhooks indica que Meta reintenta los eventos no confirmados durante hasta 7 días y que eso puede generar notificaciones duplicadas. Por lo tanto:

Deduplica por el id del mensaje (wamid). Una restricción única en la base de datos alcanza.
No confíes en el orden de llegada. Ordena los mensajes por el timestamp del evento, no por la hora en que llegó el webhook.

Estados de la conversación

Una conversación de atención necesita estados claros. Un modelo simple:

Estado	Significado	Quién actúa
`bot`	Bot o mensaje automático a cargo	Sistema
`en_cola`	Esperando un agente de un departamento	Motor de distribución
`asignada`	Un agente es dueño de la conversación	Agente
`esperando_cliente`	El agente respondió, falta el cliente	El sistema vigila la ventana de 24 h
`cerrada`	Atención resuelta	Se reabre si el cliente vuelve a escribir

El estado esperando_cliente importa por la ventana de atención de 24 horas: si el cliente tarda y la ventana se cierra, el agente solo puede retomar con una plantilla.

Reglas de distribución

No existe una regla ideal para todos los casos. Las más usadas:

Regla	Cómo funciona	Cuándo usarla
Rotación (round robin)	Siguiente agente disponible de la lista	Equipos homogéneos, demanda similar
Menor carga	Quien tiene menos conversaciones abiertas	Atenciones de duración variable
Por departamento	El bot pregunta el tema y deriva a la cola correcta	Ventas, soporte y cobranzas separados
Fidelidad	El cliente vuelve a su último agente, si está disponible	Venta consultiva, cartera de clientes
Manual (tomar de la cola)	El agente elige la siguiente conversación	Equipos pequeños, casos complejos

En la práctica, combínalas: el bot o el mensaje de bienvenida pregunta el tema, la conversación va a la cola del departamento y, dentro de la cola, se aplica menor carga con fidelidad para clientes recurrentes.

Ejemplo: asignación sin conflictos en PostgreSQL

El error más común es que dos agentes tomen la misma conversación. Con FOR UPDATE SKIP LOCKED, cada transacción bloquea la conversación que asigna y salta las que otra transacción ya tomó:

-- Asigna la conversación más antigua de la cola al agente con menos conversaciones abiertas
WITH siguiente AS (
  SELECT id
  FROM conversaciones
  WHERE estado = 'en_cola' AND departamento = 'soporte'
  ORDER BY entro_en_cola_en
  LIMIT 1
  FOR UPDATE SKIP LOCKED
),
agente AS (
  SELECT a.id
  FROM agentes a
  LEFT JOIN conversaciones c ON c.agente_id = a.id AND c.estado = 'asignada'
  WHERE a.en_linea AND a.departamento = 'soporte'
  GROUP BY a.id, a.max_simultaneas
  HAVING COUNT(c.id) < a.max_simultaneas
  ORDER BY COUNT(c.id)
  LIMIT 1
)
UPDATE conversaciones
SET estado = 'asignada', agente_id = (SELECT id FROM agente), asignada_en = now()
WHERE id = (SELECT id FROM siguiente)
  AND EXISTS (SELECT 1 FROM agente)
RETURNING id, agente_id;

Ejecútalo cuando una conversación entra en la cola y cuando un agente se libera. El campo max_simultaneas evita que alguien reciba más conversaciones de las que puede atender.

Buenas prácticas de operación

Identifica quién responde. Antepón el nombre del agente al mensaje («Ana:«). El cliente sabe con quién habla y el cambio de agente es transparente.
Transfiere con contexto. Al pasar la conversación, agrega una nota interna. El cliente no debería repetir todo.
Marca como leído solo cuando alguien leyó. El estado read muestra los dos tildes azules al cliente; envíalo cuando el agente abre la conversación, no cuando llega el webhook.
Un único punto de envío. Bot, agentes y automatizaciones deben salir por la misma capa, para respetar el throughput del número y registrar todo.
Permisos mínimos. El agente ve su cola; el supervisor ve el equipo. La guía de seguridad de la cuenta business trata los accesos al portafolio y los tokens.
Mide. Tiempo de primera respuesta, tiempo de atención y satisfacción por agente y por cola. Consulta métricas de atención en WhatsApp.

Coexistencia: el teléfono sigue funcionando

Con la coexistencia, el mismo número queda en la app WhatsApp Business y en la API a la vez. El dueño puede seguir respondiendo desde el teléfono mientras el equipo usa la bandeja. Según la documentación de coexistencia de Meta:

Los mensajes enviados desde la app llegan a tu sistema por el webhook smb_message_echoes. Muéstralos en el historial, o el agente no sabrá que el cliente ya fue atendido.
La app admite hasta cuatro dispositivos acompañantes. Los mensajes enviados desde acompañantes no compatibles (como WhatsApp para Windows) no generan webhook y no aparecen en tu sistema.
El throughput de los números en coexistencia es fijo: 20 mensajes por segundo.
Herramientas de la app como respuestas rápidas, etiquetas y mensajes de bienvenida y de ausencia no se admiten en la Cloud API.
Si el dispositivo principal queda inactivo unos 14 días, Meta envía un account_update con PARTNER_REMOVED y se cae la conexión con la API.

Para la atención multiagente, la regla práctica es: el teléfono pasa a ser un «agente» más, y tu sistema debe tratar sus mensajes como tales. El artículo sobre qué se sincroniza en la coexistencia detalla cada punto.

Cómo hacerlo con Vectalk

Vectalk es la capa de API: entrega los webhooks de Meta a tu sistema y envía las respuestas por la Cloud API oficial. Puedes registrar varias URL por instancia con POST /api/webhooks (por ejemplo, la bandeja y el CRM recibiendo el mismo evento), enviar con POST /api/messages y marcar como leído con el mismo endpoint usando status: "read". Vectalk ofrece coexistencia, así que el número puede seguir en la app. La bandeja y las reglas de distribución son de tu software. Documentación en docs.vectalk.com.br y registro en apps.vectalk.com.br/register.

Si quieres poner un bot antes de los agentes, consulta también el agendamiento automático con IA.

Preguntas frecuentes

¿Cuántos agentes puedo tener en el mismo número con la API?

Meta no limita la cantidad de agentes en la API, porque no son dispositivos de WhatsApp sino usuarios de tu sistema. El límite práctico está en tu software y en la capacidad de envío del número.

¿Puedo usar WhatsApp Web junto con la API?

Solo con coexistencia, y WhatsApp Web funciona como dispositivo acompañante de la app. Los mensajes enviados desde él llegan a tu sistema por el webhook smb_message_echoes. Sin coexistencia, un número registrado en la API no está disponible en la app ni en WhatsApp Web.

¿Cómo evito que dos agentes respondan al mismo cliente?

Asigna la conversación a un dueño antes de mostrar el campo de respuesta, con un bloqueo en la base de datos (como el FOR UPDATE SKIP LOCKED del ejemplo). Los demás ven la conversación en modo solo lectura.

¿El cliente ve el nombre del agente?

El cliente ve el nombre visible de la empresa. Si quieres mostrar quién atiende, incluye el nombre en el texto del mensaje.

¿Necesito un número por departamento?

No. Un número con colas por departamento suele ser más simple para el cliente. Los números separados tienen sentido para marcas u operaciones distintas.

Fuentes oficiales consultadas el 25/10/2026: Descripción general de webhooks, Coexistencia: incorporación de usuarios de la app WhatsApp Business, Servicio de ayuda de WhatsApp: multiagente, Docs de Vectalk: webhooks, Docs de Vectalk: marcar como leído.

Varios agentes en el mismo número de WhatsApp: cómo funciona con la API