Automatización útil sin abrir endpoints al mundo
Introducción breve
Tras montar flujos con n8n en un contexto personal, lo que aporta valor en un proceso de selección no fue exponer más superficie, sino decidir qué demostrar y qué dejar fuera del alcance del navegador en un dominio sin operación dedicada.
Problema o decisión
Un webhook público “para que vean que funciona” enseña rápido y defiende mal: abuso, coste, ruido y riesgo de contexto si el flujo toca datos o prompts. La decisión fue tratar cada URL que dispara automatización como compromiso explícito (quién llama, quién mantiene, qué pasa si falla), no como accesorio del portfolio.
Qué hice o cómo lo planteé
Planteé el caso con descripción de entrada y salida, límites del flujo y una capa intermedia (PHP entre visitante y orquestador) para no incrustar el webhook en el front ni en el repo. La fachada en servidor no sustituye autenticación fuerte: donde el endpoint sigue siendo público, añadí criterios acotados (origen, rate limit, errores genéricos al cliente). Documenté el razonamiento sin publicar UUIDs, hosts ni credenciales.
Qué aprendí
En laboral, la automatización que importa suele vivir detrás de políticas de red, identidades y monitorización acordadas; en personal, la demo útil puede ser conversación técnica completa sin convertir el dominio en blanco de abuso. Confundir demostración con despliegue productivo sale caro en ambos contextos.
Proyecto relacionado
El caso Automatización con n8n recoge la demo funcional: el visitante habla solo con chat-handler.php y la URL del orquestador queda en configuración de servidor, fuera del bundle público.