Por qué n8n nunca debe hablar directo con el sistema del cliente: arquitectura de autoservicio en WhatsApp
Demo técnica propia: automatización de autoservicio en WhatsApp con validación de identidad y ejecución vía API. El error más común de este tipo de proyecto es dejar credenciales de producción esparcidas dentro del flujo visual.
Este es un case técnico propio de Crazy Diamond — una demo de arquitectura, no un sistema entregado a cliente real. Existe para mostrar cómo estructuramos automatización de autoservicio vía WhatsApp cuando el proyecto necesita ser seguro y auditable, no solo funcionar en la demostración.
El problema que resuelve
Empresas con alto volumen de solicitudes repetitivas — proveedores de internet, clínicas, edificios, e-commerce, despachos de servicios — reciben el mismo tipo de pedido cientos de veces por mes. Cambiar una contraseña, confirmar una cita, consultar un estado, actualizar un registro. Cada uno de esos pedidos pasa hoy por un agente humano.
Automatizar esto es tentador y fácil de hacer mal. El camino rápido es montar todo el flujo dentro de una herramienta visual y dejar que llame directo al sistema de la empresa.
El error común
La herramienta de orquestación de flujo es excelente para la conversación: menú interactivo, ramificaciones, recolección de datos, timeout de sesión. Es pésima como el lugar donde viven las credenciales del ERP.
Cuando el flujo visual llama al sistema del cliente directamente, cada nodo de petición HTTP pasa a cargar credenciales de producción. No hay control de acceso real, no hay una capa que decida qué está permitido, y cualquier persona con acceso al editor del flujo pasa a tener acceso efectivo al sistema de producción. Es el error más común de este tipo de automatización.
La herramienta de flujo nunca habla directo con el sistema del cliente. Solo habla con el backend, que decide qué está permitido.
La arquitectura
El diseño separa deliberadamente las dos responsabilidades. La capa de orquestación se ocupa de la conversación. El backend se ocupa de lo que exige seguridad y lógica real: validación de identidad, reglas de negocio, idempotencia, log de auditoría y la llamada final al sistema del cliente — ERP, CRM o base de datos.
El camino completo es: cliente en WhatsApp → WhatsApp Cloud API → capa de orquestación → backend de validación y ejecución → sistema del cliente. La orquestación conversa únicamente con el backend, por red interna. Ninguna credencial de producción circula dentro del flujo visual.
El flujo demostrado
Son seis pasos, genéricos y adaptables a cualquier nicho: el cliente inicia la conversación; el flujo presenta un menú interactivo; el backend valida la identidad contra la base del cliente; el flujo recolecta los datos específicos de la solicitud; el backend ejecuta la acción vía API en el sistema del cliente; y el flujo confirma la conclusión.
Lo que cambia de un nicho a otro es solo el quinto paso. En un proveedor de internet, es el cambio de contraseña del router. En una clínica, la confirmación o reprogramación de cita. En un edificio, la autorización de visitante. En un e-commerce, la consulta de estado de pedido. La arquitectura es la misma.
Decisiones de implementación
WhatsApp Cloud API oficial de Meta, no biblioteca no oficial — automatización de atención sobre biblioteca no oficial es riesgo de bloqueo de número, y es el tipo de ahorro que sale caro.
El backend expone validación de identidad y creación de solicitud, con DTOs validados en la entrada. Cada solicitud genera un número de protocolo único. Una identidad con formato inválido es rechazada en la puerta; una identidad bien formada pero no encontrada en la base devuelve una negativa explícita, que en el flujo activa la derivación a atención humana — en vez de trabar la conversación.
La imagen del backend es multi-stage, con runtime liviano, usuario no root y healthcheck. El entorno se levanta por composición con la capa de orquestación y un proxy inverso con HTTPS automático.
Qué queda fuera, a propósito
La integración real con un ERP específico no forma parte de la demo. Esa es siempre la parte única de cada proyecto y depende enteramente del sistema del cliente. Lo que la demo prueba es la parte reutilizable: la arquitectura de orquestación y la frontera de seguridad entre la conversación y la ejecución.
Stack
WhatsApp Cloud API · n8n (self-hosted) · NestJS · TypeScript · PostgreSQL · Docker · Caddy