Adjuntos de correo en n8n: practica cómo guardar y conciliar archivos

Por Roman Rodomansky·Publicado el 22 oct 2026

Practica la gestión de adjuntos en n8n con un flujo IMAP autoalojado, registros por archivo, rutas resistentes a colisiones y conciliación manual.

• n8n
• Transformación de datos
• Depuración de flujos
• Ejercicio

Comprobado con las fuentes citadas el 22 oct 2026.

Tu ejercicio de adjuntos de correo en n8n

Construye un flujo que reciba mensajes de prueba, guarde los adjuntos de correo en n8n en una carpeta permitida y registre qué adjuntos siguen necesitando atención. Este es un ejercicio editorial: el flujo propuesto no se ha ejecutado ni validado. Su alcance se limita a un buzón desechable y a la recuperación manual de los datos de prueba.

Usa Email Trigger (IMAP) con una credencial IMAP y la salida Resolved, que la documentación describe como una salida que incluye adjuntos binarios. La implementación de la rama master de n8n, sujeta a cambios, describe este comportamiento para las versiones 2, 2.1 y 2.2 del nodo. La documentación sin fecha y las ramas de implementación sujetas a cambios pueden diferir de la versión que tengas instalada.

Creemos que merece la pena practicar la gestión de adjuntos como un problema de conciliación de registros, porque recibir un mensaje y completar su guardado responden a preguntas distintas.

Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/EmailReadImap/v2/EmailReadImapV2.node.ts at master · n8n-io/n8n · GitHub

Prepara el buzón, la carpeta y los registros

Prepara una instancia autoalojada de n8n, un buzón IMAP desechable, credenciales que funcionen y una ruta de destino absoluta con permisos de escritura. En n8n autoalojado, a partir de la versión 2.0, la restricción documentada de acceso a archivos tiene como valor predeterminado ~/.n8n-files. Las rutas de Docker hacen referencia al sistema de archivos del contenedor; prepara un montaje de volumen para un directorio del host y comprueba la configuración de directorios permitidos de tu versión instalada.

Crea Data Tables con las siguientes columnas sugeridas antes de construir el flujo. El registro de adjuntos utiliza operaciones documentadas de upsert, consulta y actualización; estos nombres de columna son una propuesta editorial.

Sources: Read/Write Files from Disk | Nodes | n8n Docs, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub

Desglosa los mensajes en elementos por adjunto

Para este ejercicio de descarga de adjuntos de correo en n8n, envía mensajes sintéticos con identificadores de caso de prueba explícitos y únicos. Usa estos datos de prueba sugeridos y anota los nombres de los adjuntos esperados antes de ejecutar nada.

Inspecciona las propiedades binarias reales de la salida Resolved. Una respuesta de n8n Community de 2025 sobre Gmail muestra cómo no devolver elementos de adjuntos cuando faltan datos binarios y cómo convertir las propiedades binarias en elementos individuales. Adaptar ese patrón a IMAP es una propuesta editorial: omite su filtro de extensiones, conserva los metadatos del mensaje y asigna a cada elemento de salida un único adjunto en un campo binario uniforme, como attachment.

Escribe un registro de recepción antes del desglose para que la rama vacía no oculte el caso sin adjuntos. Para los correos de n8n con varios adjuntos, asigna a cada adjunto de prueba un ordinal registrado y conserva esa asignación al preparar otro intento. Después de guardar el caso REPEAT, reenvía manualmente su contenido sin cambios, con el identificador de caso de prueba y los ordinales originales de los adjuntos, para poner a prueba la comprobación de registros existentes.

Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, Getting only the correct attachment - Questions - n8n Community

Elige claves estables y registra los guardados previstos

Usa esta secuencia sugerida para nombrar y guardar adjuntos de correo en n8n. El nodo Crypto admite el cálculo de hashes SHA256; Read/Write Files from Disk requiere una ruta de destino y un campo binario de entrada. La implementación de escritura en disco de la rama master de n8n, sujeta a cambios, utiliza indicadores que truncan el archivo cuando Append está desactivado, por lo que repetir las rutas de destino puede sobrescribir archivos.

1. Construye la clave del adjunto a partir del identificador de caso de prueba asignado y del ordinal registrado.
2. Busca esa clave antes de cambiar su estado en el registro. Envía todos los registros existentes a conciliación antes de permitir otra escritura.
3. Para una clave nueva, calcula su hash SHA256; utiliza el hash y una extensión controlada dentro de la carpeta permitida.
4. Para un registro nuevo, realiza un upsert con la clave, los metadatos, la ruta prevista, el estado pending y attempt_count a cero. Conserva las rutas y los contadores existentes durante la recuperación, salvo al corregir el destino deliberadamente no válido.
5. Desactiva los reintentos automáticos del nodo de escritura en disco del ejercicio. Justo antes de cada invocación explícita de escritura de un adjunto, guarda el estado pending e incrementa una vez el attempt_count de ese registro; detente si esa actualización falla. La recepción, las búsquedas, las comparaciones y las escrituras omitidas no lo incrementan.
6. Escribe el campo binario attachment en el destino guardado con Append desactivado.
7. Tras completarse correctamente, actualiza el registro correspondiente a saved; dirige la salida de error independiente para registrar needs-another-attempt y los detalles del error.

Por ejemplo, la clave REPEAT:1 se convierte en un nombre base SHA256 seguido de una extensión .txt controlada dentro de la carpeta permitida. REPEAT:2 genera un destino derivado por separado, aunque comparta el nombre de archivo original. Guarda la ruta elegida y reutilízala durante la recuperación. Este sistema de nombres es resistente a colisiones, pero no está exento de ellas ni proporciona una deduplicación segura ante ejecuciones concurrentes.

En nuestra opinión, en este ejercicio los nombres de archivo originales deben conservarse como metadatos; dejar que determinen las rutas del sistema de archivos añade una distracción antes de que la lógica de recuperación esté clara.

Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/Files/ReadWriteFile/actions/write.operation.ts at master · n8n-io/n8n · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.crypto.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub, skills/skills/n8n-error-handling-official/SKILL.md at main · n8n-io/skills · GitHub

Concilia los registros sin terminar antes de otro intento

Recupera los registros con estado pending y needs-another-attempt. Para este procedimiento editorial de conciliación, inspecciona cada archivo esperado antes de repetir una escritura: el archivo puede existir aunque haya fallado la actualización de estado. Compara sus bytes con los del adjunto sintético conservado. Si coinciden, marca el registro como saved sin reescribir el archivo ni incrementar attempt_count. Si el archivo no existe, recupera manualmente el adjunto y reintenta mediante la secuencia de escritura con comprobaciones. Conserva cualquier archivo que no coincida, registra la discrepancia y deja el adjunto pendiente de atención para investigarlo.

Aplica también esta comprobación a los registros saved existentes al volver a procesarlos, antes de cualquier upsert a pending o escritura. Correlaciona los fallos mediante la clave del adjunto, sin dar por hecho que la salida de error conserva todos los campos originales. Usa coincidencia AND explícita para los filtros compuestos del registro; la referencia advierte que algunas versiones usan OR de forma predeterminada y que una actualización que no encuentra coincidencias no hace nada.

El correo se marca como leído cuando n8n lo recibe, por lo que el estado no leído no demuestra que se haya completado el guardado del archivo. En la implementación IMAP de la rama master de n8n, sujeta a cambios, las versiones 2.1 y posteriores del nodo ofrecen Fetch Only New Emails basándose en la última ejecución; dejar un mensaje sin leer no garantiza que vuelva a procesarse. Recupera el binario del correo de prueba conservado o reenvía manualmente el caso con su clave de prueba original.

Este diseño no garantiza una entrega exactamente una vez ni una coordinación atómica entre los archivos y las actualizaciones del registro. Este ejercicio no proporciona un mecanismo automático y duradero de reprocesamiento ni garantiza la retención de mensajes.

Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub, skills/skills/n8n-error-handling-official/SKILL.md at main · n8n-io/skills · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/nodes-base/nodes/EmailReadImap/v2/EmailReadImapV2.node.ts at master · n8n-io/n8n · GitHub

Comprueba la finalización y explica la limitación pendiente

Usa esta lista editorial como criterio de finalización para los adjuntos de correo en n8n, sin considerarla una evaluación validada.

• El mensaje sin adjuntos tiene un registro de recepción.
• Cada adjunto esperado tiene su propio elemento de trabajo, registro de seguimiento y archivo previsto que coincide con el adjunto sintético conservado.
• Los nombres de archivo originales repetidos tienen destinos distintos.
• Un fallo provocado por una ruta no válida sigue siendo identificable, con su error y un attempt_count de uno.
• Después de corregir el destino y recuperar manualmente el caso de prueba, una segunda escritura correcta deja un archivo coincidente, el estado saved y un attempt_count de dos.
• Reenviar el contenido de REPEAT sin cambios, con el identificador y los ordinales originales, mantiene los mismos registros de adjuntos, rutas y bytes de los archivos, sin escrituras adicionales ni incrementos del contador.
• Un archivo coincidente con estado sin terminar pasa a saved sin reescribirse; un archivo que no coincide se conserva y queda señalado para su investigación.

Si alguna comprobación falla, inspecciona las credenciales y la selección del buzón, los nombres reales de los campos binarios, los directorios permitidos, los montajes de Docker y las coincidencias de los filtros del registro. Como reflexión, explica cómo distinguirías un archivo ausente de una escritura completada cuya actualización de registro haya fallado, y qué pruebas justificarían cambiar su estado.

Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.emailimap.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile.md at main · n8n-io/n8n-docs · GitHub, Read/Write Files from Disk | Nodes | n8n Docs, skills/skills/n8n-data-tables-official/references/OPERATIONS.md at main · n8n-io/skills · GitHub, skills/skills/n8n-error-handling-official/SKILL.md at main · n8n-io/skills · GitHub