Baileys en la práctica: lo que aprendimos operando un clúster no oficial

Baileys es una biblioteca que automatiza WhatsApp Web: abre una sesión como si fuera un navegador vinculado y envía mensajes por ella. Es gratuita, arranca en minutos y no pide aprobación de nada. También infringe los términos de WhatsApp, y la sesión que mantiene es el punto único de fallo de cualquier operación construida encima.

Este texto no es una reseña: es lo que aprendimos operando un clúster de esas instancias en producción, con clientes de pago, antes de migrarlos a la Cloud API.

Lo que funciona bien

Conviene empezar por lo que es cierto y suele omitir quien vende la alternativa:

• Arranca en minutos. Instalas, escaneas el código QR, envías.
• No cobra por mensaje. Para volumen alto de notificación, la diferencia de coste es de órdenes de magnitud.
• No exige aprobación de plantillas. Escribes y mandas.
• Hace cosas que la API oficial no hace: grupos, sobre todo.

Para un prototipo, un uso interno o un volumen bajo en un número prescindible, es difícil justificar otra cosa.

El fallo que no aparece en la monitorización

La sesión de WhatsApp Web no sobrevive a un reinicio. Eso está en la documentación de cualquier proyecto del tipo y todo el mundo lo sabe, en teoría.

En nuestro clúster, dos servidores se reiniciaron el mismo día. Ese día, 41 instancias entraron en estado de reconexión y no volvieron solas. La fecha de última actualización de las 41 era idéntica. Lo descubrimos semanas después, al medir el clúster para planificar la migración.

El servicio siguió en pie, respondiendo a las peticiones de estado, consumiendo recursos e informando de que estaba sano. Solo que no tenía sesión. Un fallo silencioso es peor que una caída: una caída alguien la nota.

Es el tipo de problema que no se resuelve con más monitorización genérica. «El proceso está corriendo» y «el endpoint responde 200» seguían siendo verdad. La pregunta correcta —«¿esta instancia tiene sesión válida ahora mismo?»— hay que hacerla explícitamente, instancia a instancia.

Qué se rompe, por frecuencia

1. Reinicio del servidor. La sesión muere y no vuelve sin reconexión manual o automatización específica.
2. Actualización de la aplicación. La biblioteca persigue al protocolo, y hay una ventana en la que simplemente no funciona.
3. Vinculación caducada. Las sesiones envejecen y caen sin un evento claro.
4. Bloqueo del número. Sin aviso, sin plazo y sin recurso previsible.

Los tres primeros son operativos y se mitigan con trabajo. El cuarto no se mitiga: es consecuencia de automatizar WhatsApp Web, que es lo que la biblioteca hace por definición.

El coste que no estaba en la hoja de cálculo

La cuenta que suele justificar la elección compara la tarifa de Meta por mensaje con cero. Ignora tres líneas:

• Operación — servidores, reconexiones, alguien de guardia para levantar sesiones, monitorización específica.
• Pérdida por fallo silencioso — mensajes que la tienda cree haber enviado y no envió.
• Sustituir el número — cuando el número que cae es el mismo de atención, el coste no es el número: es el cliente que no consigue hablar contigo.

Fue la suma de esas tres, y no el importe de la tarifa, lo que nos llevó a apagar el clúster y llevar a los clientes a la Cloud API.

Cuándo sigue teniendo sentido

No es una condena. La biblioteca sigue siendo la elección correcta en algunos casos:

• Una prueba de concepto que va a durar dos semanas.
• Automatización interna, en un número que no es el del negocio.
• Una operación que depende de grupos, que la API oficial no atiende de ninguna manera.
• Volumen alto de notificación donde la cuenta de la API oficial demostrablemente no cierra.

Lo que cambia la respuesta es una pregunta: si este número deja de funcionar mañana, ¿qué le pasa a la empresa?

Si la decisión es migrar

La migración conserva el número, siempre que no esté bloqueado y se cierre antes la sesión antigua. Lo que no migra son los textos: en la API oficial, un mensaje que parte de ti es una plantilla aprobada.

El paso a paso está en migrar a la API oficial de WhatsApp, y la comparación criterio a criterio en API oficial vs API no oficial.

Preguntas frecuentes

¿Baileys es seguro?

El código es maduro y está mantenido. El riesgo no está ahí: está en el método, porque automatizar WhatsApp Web infringe los términos y expone el número a un bloqueo.

¿Se puede usar Baileys sin que bloqueen el número?

Se puede reducir la probabilidad —volumen bajo, consentimiento, sin envío masivo—. No se puede eliminar, porque la infracción es el uso, no el contenido.

¿Cuál es la diferencia entre Baileys y la Cloud API?

Baileys automatiza WhatsApp Web por ingeniería inversa; la Cloud API es la interfaz oficial de Meta, alojada por ella, donde automatizar es el uso previsto y cada plantilla iniciada se cobra.

¿La sesión de Baileys se puede persistir?

Las credenciales pueden guardarse y recargarse, lo que ayuda. No elimina el problema: la sesión sigue caducando, sigue rompiéndose al actualizar y sigue necesitando reconexión vigilada.