Un espacio aparte del foro publico para coordinar detalles que no van en un hilo abierto: compartir un payload con datos de cliente, revisar juntos un log de n8n antes de publicarlo, o pasar la credencial de un webhook de prueba sin exponerla. Aqui llegan las conversaciones que empiezan en un hilo sobre orquestacion y siguen por dentro, con el mismo criterio de siempre: capturas reales, contexto suficiente y feedback sin humo.
La pagina de mensajes existe para algo concreto: que dejes de resolver tus flujos a ciegas. Aqui no vendemos cursos ni plantillas milagrosas. Se comparten errores reales, capturas de nodos que fallaron a las 3 de la manana y decisiones tecnicas que ya pasaron por produccion en equipos de Peru y Latinoamerica.
Si recien empiezas con n8n o Make, hay un hilo de bienvenida con la ruta minima. Si ya vendes automatizaciones a pymes, vas directo a los debates de costos por ejecucion y limites de contexto.
Ver como se organizan las secciones del foro o escribir al equipo de moderacion si algo no encaja.
Cuando publicas un flujo roto, la comunidad pregunta primero por el trigger, el payload y los logs. Eso evita el tipico parche que tapa el sintoma y vuelve a caer la semana siguiente.
Los flujos compartidos vienen con notas de que se rompio, que se cambio y por que. No son demos de laboratorio: son automatizaciones que aguantaron volumen real y clientes exigentes.
Se discute cuando conviene RAG y cuando un prompt encadenado basta. Tambien cuando migrar de low-code a Python y cuando no vale la pena tocar lo que ya funciona.
Publicas tu flujo, tu scraper o tu agente y recibes criticas concretas: nombres de nodos, orden de ejecucion, manejo de errores. Nadie te va a decir "excelente trabajo" si el webhook no tiene reintentos.
La mayoria trabaja desde Peru, Chile, Mexico o Colombia, con las mismas limitaciones de proveedores, facturacion y soporte. Eso cambia las recomendaciones frente a foros en ingles.
Si un flujo se cayo a las 3 de la manana, el primer paso es saber por donde escribir y cuanto vas a esperar. Aqui esta el detalle de cada via de contacto, con horarios reales de moderacion y el tipo de consulta que atiende mejor cada una.
La via mas rapida para dudas tecnicas sobre n8n, Make o Zapier. Publica el hilo con el nodo que falla, el payload de entrada y el error completo. La comunidad responde en horario Lima, y los hilos activos suelen tener respuesta en menos de 4 horas.
Respuesta tipica: 2 a 6 horas en dias habilesPara casos que no conviene exponer en publico: credenciales mal rotadas, limites de ejecucion de tu cuenta o problemas con la moderacion. Escribe a info@dnagents.com con el asunto del hilo y un resumen del contexto.
Respuesta tipica: 24 a 48 horasReservado para temas de comunidad, alianzas con pymes o consultas sobre el directorio de flujos compartidos. No es soporte tecnico de urgencia: si tu scraper se rompe, mejor abre un hilo en el foro.
Atencion: +51 1748745, lunes a viernesReportes de spam, hilos duplicados o discusiones que se salen de tono. La moderacion es ligera y busca mantener el respeto por el trabajo de cada uno, sin censurar criticas tecnicas bien argumentadas.
Revision: 1 vez al dia, en horario nocturnoAntes de escribir, revisa el centro de guias: muchas dudas sobre webhooks, reintentos y limites de contexto ya estan resueltas ahi. Si tu caso es distinto, entonces si vale la pena abrir un hilo nuevo.
Tambien puedes revisar las condiciones de uso y la politica de privacidad si tu consulta es sobre datos o contenido publicado.
Un resumen cada dos semanas con lo que se movio en el foro: plantillas de flujos nuevas, errores que otros ya resolvieron y discusiones sobre limites de ejecucion. Sin relleno y sin promesas de resultados.
Si estas armando agentes con n8n, Make o Zapier y todavia no tienes claro por donde empezar, la lista de correo funciona como un punto de entrada. Recibes los hilos que mas respuestas generaron, los fragmentos de codigo que la gente compartio y avisos cuando abrimos una seccion nueva. Nada de contenido generico: lo que se publica aca sale de flujos que alguien corrio de verdad.
Para quienes ya venden automatizaciones a pymes, tambien sirve para ver como otros manejan clientes que piden cambios a ultima hora o integraciones que no estaban en el alcance inicial. La idea es simple: menos ruido, mas casos concretos.
Arme un flujo en n8n que recibe eventos de una pasarela y los manda a un CRM. Cuando el proveedor responde 502, n8n reintenta y el CRM crea el contacto dos veces. Como lo resuelven sin meter una cola externa todavia?
Lo mas simple es guardar el id del evento en una tabla y chequear antes de escribir. Si ya existe, cortas el flujo. No es elegante pero aguanta miles de ejecuciones sin tocar Redis.
Ojo con el nodo de reintentos por defecto: reintenta ante cualquier error, incluido un 400 de validacion. Ahi duplicas sin necesidad. Separen errores de red de errores de negocio antes de decidir el reintento.
Nosotros terminamos usando una idempotency key generada en el trigger y un dead letter node para los payloads que fallan tres veces seguidas. Desde entonces no perdemos eventos y podemos reprocesar a mano.
Gracias, voy a probar la tabla de ids primero y medir cuantas ejecuciones extra me ahorra antes de meter cola. Subo capturas del antes y despues en el hilo del canal.