Un foro técnico en español para quienes dejan de jugar con demos y empiezan a sostener sistemas reales: n8n, Make, Zapier, prompts encadenados, RAG sobre bases vectoriales, webhooks que reciben datos de terceros y scrapers que se rompen justo cuando nadie está mirando. Aquí se comparten plantillas de flujos, capturas de errores tal como aparecen en los logs y discusiones sin humo sobre límites de contexto, costos por ejecución y el paso incómodo de un prototipo de fin de semana a algo que corre estable.
Hay espacios para quien recién arma su primer flujo, para devs que migran de low-code a Python cuando la plataforma visual ya no alcanza, y para quienes venden automatizaciones a pymes y necesitan documentar lo que entregan. La comunidad es de Perú y Latinoamérica, con moderación ligera y respeto por el trabajo ajeno.
Publica tu primer flujo y pide feedbackAntes de escribir, revisa soluciones y enfoques por tipo de proyecto o lee un caso real en orquestar n8n con webhooks que no se caen.
En DN Agents hay espacio para prototipos, pruebas a medias y errores sin resolver, pero conviene aclarar cómo leemos cada cosa. Estas notas evitan discusiones repetidas sobre lo mismo y ayudan a que el feedback que recibas sirva de verdad. Si algo no calza con lo que está aquí, lo conversamos en el hilo correspondiente.
No exigimos que tu flujo tenga miles de ejecuciones diarias ni un equipo detrás. Consideramos producción a cualquier automatización que ya recibe datos reales de terceros, corre en un horario fijo o afecta a alguien fuera de tu máquina. Un scraper que se ejecuta cada mañana y alimenta un reporte interno cuenta. Un experimento que solo tú disparas a mano, todavía no. La distinción importa porque los consejos cambian: reintentos, alertas y respaldos tienen sentido cuando ya hay algo que se puede romper sin que estés mirando.
Aquí se trabaja con n8n, Make y Zapier, y eso no rebaja el nivel de la conversación. Cuando alguien comparte un flujo, esperamos ver el trigger, los nodos principales y qué pasa cuando una API responde con error. Pegar una captura del editor visual sirve, pero un JSON exportado o un fragmento del payload que falló ayuda mucho más. Tampoco aceptamos respuestas del tipo "usa otra herramienta" sin explicar por qué, con qué costo operativo y qué se gana en mantenimiento. La idea es que quien lea pueda replicar la solución, no solo admirarla.
Los debates sobre cantidad de contexto, chunking y re-ranking son bienvenidos, siempre que vengan con un caso concreto. "Mi agente alucina" no es un problema, es un síntoma. Necesitamos saber qué documentos indexaste, cómo los dividiste, qué modelo usas y en qué pregunta falló. Lo mismo con los prompts encadenados: si compartes la cadena completa, otros pueden señalar dónde se pierde la instrucción. Cuando alguien pide ayuda con RAG, la primera pregunta del hilo suele ser si realmente lo necesita o si un prompt bien acotado resolvía el caso con menos piezas moviéndose.
Hablamos de consumo por ejecución, límites de plan y cuánto pesa cada llamada a un modelo, porque eso define si un flujo aguanta el mes o se cae a la semana. Lo que no entra es contenido de inversión, señales, apuestas ni promesas de retorno. Si tu automatización es para un negocio, describe el proceso y las restricciones operativas, no las cifras de facturación. La moderación es ligera, pero ese punto se sostiene sin excepción porque cambia por completo el tipo de comunidad que queremos mantener.
Cuando pidas revisión, di qué esperabas y qué obtuviste. Así el comentario apunta al problema y no a la persona. Se puede decir que un enfoque no escala, que un nodo está mal ubicado o que la lógica de reintentos va a duplicar registros; lo que no se hace es burlarse del nivel de quien pregunta. Hay secciones para principiantes y para devs que migran de low-code a Python, y cada una tiene su propio ritmo. Si tu respuesta no aporta un dato, una prueba o una alternativa concreta, mejor guárdala para otro hilo.
Compartir plantillas de flujos es una de las mejores cosas que tiene el foro. Al hacerlo, quita credenciales, tokens de API, correos y cualquier identificador de clientes antes de publicar. Las capturas de errores reales valen mucho, sobre todo cuando incluyen la hora y el código de respuesta, pero tapa lo que no corresponde mostrar. Si trabajas con datos de una pyme, anonimiza el caso. Un flujo que se rompe a las 3 de la mañana se puede contar sin exponer a nadie, y esa costumbre mantiene la confianza entre quienes participan.
No hace falta limpiar el JSON ni esconder los nodos feos. Sube la captura del canvas, pega el export de n8n o Make y cuenta en dos lineas que deberia pasar cuando entra el webhook. Si el flujo ya vive en produccion, mejor: ahi aparecen los problemas que no se ven en un demo.
La moderacion es ligera, pero responder con humo no sirve. Los hilos donde alguien dice "revisa el nodo de reintentos" o "tu idempotency key se repite por evento" avanzan rapido. Los que solo piden "que alguien me lo arregle" se quedan quietos.
Aca se comparan logs, se pegan respuestas 502 del proveedor y se revisa si el problema esta en el trigger, en el prompt encadenado o en la base vectorial. Es normal que un hilo derive hacia limites de contexto o costos por ejecucion cuando el caso lo justifica.
Nadie toca tu instancia. Te llevas la idea, la adaptas a tu stack y vuelves con el resultado. Si el flujo aguanta un fin de semana corriendo sin caerse a las 3 de la manana, ese es el dato que interesa compartir despues.
El hilo cerrado con la solucion se convierte en plantilla o en referencia para quien migra de low-code a Python, o para quien vende automatizaciones a pymes y necesita algo estable. Eso es lo que sostiene la comunidad tecnica peruana y latinoamericana.
El foro no es un canal de soporte ni una vitrina. Es una secuencia corta: entras con un problema concreto, lo expones sin adornos, y sales con una version del flujo que aguanta produccion. La mayoria de los temas arrancan con un webhook que falla, un scraper que devuelve vacio o un agente que responde cualquier cosa cuando el contexto se llena.
Si recien empiezas, publica igual. Hay secciones para principiantes y para devs que ya migran de Make a Python. Lo unico que pedimos es respeto por el trabajo del otro y feedback honesto, sin humo.
Antes de publicar, revisa las soluciones que ya estan armadas y el hilo de orquestacion con webhooks que no se caen a las 3 AM. Muchas dudas repetidas ya tienen respuesta ahi.
Si ya armaste un flujo en n8n que corre bien en tu maquina pero se cae cuando lo dejas solo un fin de semana, este es el lugar para traerlo. En DN Agents se comparten plantillas, capturas de errores reales y discusiones sobre reintentos, colas y webhooks que no avisan cuando fallan.
No hace falta tener todo resuelto. Basta con describir que dispara el flujo, que APIs toca y donde se rompe. Alguien del foro ya paso por lo mismo con Make, Zapier o un scraper que devolvia 502 a las 3 de la manana.
Escribir al equipo del foroAntes de publicar, revisa las soluciones por tipo de flujo o lee el hilo sobre orquestar n8n con webhooks estables.