Caricare un file da un flusso n8n

Il nodo n8n dosya.dev carica un file binario da una fase precedente del flusso in uno spazio di lavoro dosya scelto. Scegli Risorsa → File e Operation → Upload. Un URL in un campo JSON non è l’input binario richiesto da questa operazione.

Configura il nodo e la credenziale

In un’istanza n8n ospitata da te, un proprietario o amministratore può aprire Settings → Community Nodes → Install, inserire n8n-nodes-dosya, leggere l’avviso sul codice della community e scegliere Installa. L’istanza deve consentire i pacchetti community. Il pacchetto attuale è 0.1.1 e richiede Node.js 20.15 o successivo. Se il nodo manca, verifica installazione e regole dell’amministratore n8n invece di cercare il campo di destinazione in un altro nodo.

Crea una credenziale di tipo dosya.dev API. L’unico campo segreto è API Key. In Profilo → Chiavi API di dosya crea una chiave con ambito Accesso completo, API REST attivato e senza ancoraggio a una cartella; puoi vincolarla allo spazio di lavoro usato dal flusso. Inserisci il segreto completo, non il prefisso mostrato. Il test rifiuta una chiave di sola lettura con This key is read-only. Uploads, folders and share links need a key with Full access scope. Le chiavi per il solo caricamento non superano le operazioni di account ed elenco usate dal nodo.

Il ruolo del proprietario della chiave nello spazio di lavoro deve consentire i caricamenti e la destinazione scelta deve rispettare le limitazioni alle cartelle del membro. L’accesso completo è un ambito della credenziale, non un ruolo di amministratore. Valgono scadenza, indirizzi e orari consentiti, quota di archiviazione, regole sui tipi di file e limiti espliciti di dimensione o trasferimento. Il nodo non può aggirarli.

Passaggi: crea un flusso per un file piccolo

1. Aggiungi un trigger manuale e un nodo HTTP Request. Usa GET con un URL HTTPS diretto a un piccolo file di esempio sotto il tuo controllo. In Options → Response, imposta Response Format → File e Put Output in Field → data. Esegui il nodo e apri la scheda Binary del suo output. Verifica che data contenga i byte, il nome e il tipo previsti. Non includere segreti nell’URL di esempio.
2. Collega un nodo dosya.dev e scegli la credenziale salvata dosya.dev API. Imposta Risorsa → File e Operation → Upload.
3. Imposta Spazio di lavoro con From List o By ID (ws_…). Imposta Cartella sulla destinazione; lascialo vuoto o scegli radice dello spazio di lavoro per il primo livello. Gli ID cartella iniziano con fld_. Un membro con accesso limitato deve scegliere una cartella in cui può scrivere, senza presumere che la radice sia accessibile.
4. Imposta Input Data Field Name su data. Se il nodo precedente usa attachment_0 o un altro nome, inserisci l’esatto nome della proprietà nella scheda Binary. È il nome del campo, non il nome del file né un’espressione JSON che restituisce un URL.
5. Imposta Nome file su un nome di prova univoco con estensione, per esempio n8n-proof-20261014.txt. Se lo lasci vuoto viene mantenuto il nome in ingresso; se manca, si usa file. Se il nome sostitutivo non ha estensione, viene aggiunta quella dei dati binari quando disponibile.
6. Esegui una volta il nodo dosya. Confronta id, name, size, workspace_id e folder_id restituiti con la destinazione prevista prima di attivare esecuzioni pianificate o basate su eventi.

Per nomi variabili, imposta Nome file su un’espressione come {{ $json.outputName }} quando il JSON in ingresso contiene effettivamente outputName. I selettori di spazio di lavoro e cartella supportano valori By ID ricavati da fasi precedenti. I parametri del nodo vengono risolti per ogni elemento in ingresso; un’espressione vuota non sceglie una destinazione. Resource e Operation sono opzioni fisse, non espressioni di dati.

Verifica il risultato

Apri File in dosya nello spazio di lavoro e nella cartella scelti. Verifica nome univoco del file di prova, dimensione e contenuto. L’output del caricamento contiene metadati JSON, non i byte caricati né un URL pubblico di condivisione. Include id, name, size, mime_type, version, is_new_version, workspace_id, folder_id, created_at, hash_verified, deduplicated e upload_method. Un caricamento nella radice ha folder_id: null.

Un nome nuovo crea un file; un nome visibile già presente nella stessa cartella crea un’altra versione di quel file. is_new_version indica se la versione restituita è maggiore di 1. Un nome di prova diverso evita che la verifica sostituisca il contenuto attuale di un file esistente. Il caricamento non crea un link di condivisione per i destinatari; usa una fase Condividi link → Crea solo quando intendi condividere.

Dimensioni, tempi ed esecuzioni ripetute

I file fino a 52.428.800 byte (50 MiB) usano una sola richiesta. Per dati binari più grandi si usa una sessione multipart con parti sequenziali della dimensione indicata dalla risposta di dosya. I dati binari n8n archiviati vengono letti come flusso per il multipart; i dati base64 incorporati sono già in memoria. Questo elimina il limite della singola richiesta, ma valgono ancora i limiti di piano, spazio di lavoro e chiave e la capacità dell’host n8n.

Le richieste di caricamento, parte e completamento consentono 10 minuti ciascuna; le richieste API ordinarie usano 60 secondi. Le richieste sicure in caso di errori temporanei vengono tentate al massimo 3 volte. Le attese per limiti di frequenza superiori a 30 secondi vengono segnalate al flusso affinché le gestisca, senza bloccare il nodo indefinitamente. Usa un nodo Wait o una strategia di ripetizione esplicita per attese più lunghe.

Il caricamento con una sola richiesta deriva una chiave di idempotenza da esecuzione, nodo, elemento, destinazione, nome e contenuto. Un nuovo tentativo dello stesso caricamento può restituire il risultato salvato con deduplicated: true. Una nuova esecuzione del flusso ha una chiave diversa; lo stesso nome può quindi creare una nuova versione. Le parti multipart possono essere ritentate in sicurezza, ma un’inizializzazione o un completamento dal risultato incerto non vengono inviati di nuovo automaticamente. In caso di errore il nodo tenta di interrompere la sessione multipart aperta. Controlla dosya prima di ripetere un’esecuzione scaduta; non presumere che nessun file sia stato salvato.

Risolvi il problema del campo o della risposta

Errore	Azione
No workspace selected	Scegli Workspace o correggi l’ID mappato. Workspace IDs start with ws_ indica un ID manuale non valido.
Input binario mancante	Esegui la fase precedente che produce il file e controlla Binary. Copia il nome della proprietà in Input Data Field Name; gli elementi solo JSON non possono essere caricati.
dosya.dev did not accept the API key	Sostituisci nella credenziale una chiave digitata male, scaduta o revocata.
403 con anchored at a folder	Usa una chiave abilitata per API senza ancoraggio a cartella; gli ancoraggi funzionano con WebDAV/S3, non con questo nodo REST.
Altro 403 o destinazione invisibile	Controlla il vincolo della chiave allo spazio di lavoro, il ruolo del membro e l’accesso alla cartella. Cambiare File Name non ripristina un permesso scaduto.
413	Controlla il limite effettivo di dimensione del file per piano, spazio di lavoro o chiave. Il multipart non lo supera.
Rifiuto per limite di spazio	Libera spazio adeguato o chiedi all’amministratore dello spazio di lavoro di aumentare il limite; un limite dello spazio non richiede necessariamente un piano superiore.
dosya.dev did not open a multi-part upload	Riprova dopo aver verificato lo stato del servizio. Se il problema persiste, conserva i dettagli dell’esecuzione per l’assistenza.
429	Rispetta l’attesa indicata, riduci le esecuzioni parallele del flusso o inserisci un Wait tra i gruppi.

Risultato previsto

Ogni elemento in ingresso elaborato correttamente produce metadati del file per la destinazione giusta e può essere confrontato con i dati binari originali. Disconnettere la credenziale n8n o revocarne la chiave interrompe l’uso futuro dell’API; i file già caricati restano in dosya, comprese le versioni create dalle esecuzioni precedenti.

Guide correlate

• Connettere dosya a n8n
• Creare un flusso n8n