n8nワークフローからファイルをアップロード

dosya.devのn8nノードは、ワークフローの前のステップから受け取ったバイナリファイルを、選択したdosyaワークスペースにアップロードします。Resource → FileとOperation → Uploadを選択してください。JSONフィールド内のURLは、この操作が必要とするバイナリ入力ではありません。

ノードと認証情報を設定

セルフホストのn8nインスタンスでは、Owner/AdminがSettings → Community Nodes → Installを開き、n8n-nodes-dosyaを入力して、コミュニティコードに関する確認事項を確認し、インストールを選択できます。インスタンスでコミュニティパッケージが許可されている必要があります。現在のパッケージは0.1.1で、Node.js 20.15以降が必要です。ノードが見つからない場合は、別のノードで送信先フィールドを探すのではなく、パッケージのインストール状況とn8n管理者のポリシーを確認してください。

dosya.dev APIタイプの認証情報を作成してください。シークレットフィールドはAPI Keyのみです。dosyaの**プロフィール → API（APIキー）**で、フルアクセススコープ、REST APIを有効、フォルダーアンカーなしのキーを作成します。ワークフローで使う1つのワークスペースに固定することもできます。表示された接頭辞ではなく、シークレット全体を入力してください。認証情報のテストはRead onlyキーを拒否し、**This key is read-only. Uploads, folders and share links need a key with Full access scope.**と表示します。Upload onlyキーでは、このノードが使うアカウントや一覧取得の操作に合格できません。

キーのオーナーのワークスペースロールでアップロードが許可され、選択した送信先がメンバーのフォルダー制限の範囲内にある必要があります。Full accessは認証情報のスコープであり、管理者ロールではありません。キーの有効期限、許可されたアドレスと時間帯、ストレージ容量、ファイル形式のポリシー、明示的な容量や転送の制限も引き続き適用されます。ノードでこれらを回避することはできません。

手順：小さいファイルのワークフローを作成

1. 手動トリガーとHTTP Requestノードを追加してください。自分で管理する小さいサンプルファイルへの直接HTTPS URLに対してGETを使います。Options → ResponseでResponse Format → FileとPut Output in Field → dataを設定します。そのノードを実行し、出力のBinaryタブを開いてください。dataに想定するバイトデータ、ファイル名、種類があることを確認します。サンプルURLにシークレットを含めないでください。
2. dosya.devノードを接続し、保存したdosya.dev API認証情報を選択してください。Resource → FileとOperation → Uploadを設定します。
3. From ListまたはBy ID（ws_…）でWorkspaceを設定してください。Folderに送信先を設定し、最上位に保存する場合は空のままにするかWorkspace Rootを選択します。フォルダーIDはfld_で始まります。アクセス範囲が制限されたメンバーは、ワークスペースのルートにアクセスできると決めつけず、書き込み可能なフォルダーを選択してください。
4. Input Data Field Nameをdataに設定してください。前のノードがattachment_0など別の名前を使っている場合は、Binaryタブのプロパティ名を正確に入力します。これはフィールド名であり、ファイル名やURLを返すJSON式ではありません。
5. File Nameにn8n-proof-20261014.txtなど、拡張子を含む固有のテスト名を設定してください。空のままにすると入力されたファイル名を使い、ファイル名がない場合はfileを使います。指定した名前に拡張子がない場合、バイナリの拡張子があれば付加されます。
6. dosyaノードを1回実行してください。スケジュールやイベントによる実行を有効にする前に、返されたid、name、size、workspace_id、folder_idを目的の送信先と比較します。

ファイル名が変わる場合、入力JSONに実際にoutputNameが含まれているときは、File Nameを{{ $json.outputName }}のような式に切り替えてください。ワークスペースやフォルダーのロケーターは、前のステップからマッピングしたBy ID値に対応しています。ノードのパラメーターは入力項目ごとに解決されます。空の式では送信先は選択されません。ResourceとOperationはデータ式ではなく固定の選択肢です。

結果を確認

選択したワークスペースとフォルダーでdosyaのファイルを開いてください。固有のテストファイル名、容量、内容を確認します。アップロードの出力はJSONメタデータであり、アップロードしたバイトデータや公開共有URLではありません。id、name、size、mime_type、version、is_new_version、workspace_id、folder_id、created_at、hash_verified、deduplicated、upload_methodが含まれます。ルートへのアップロードではfolder_id: nullになります。

新しい名前ではファイルが作成されます。同じフォルダーに表示される既存のファイル名では、そのファイルの新しいバージョンが作成されます。is_new_versionは返されたバージョンが1を超えるかどうかを示します。別のテスト名を選ぶと、設定の確認によって既存ファイルの現在の内容が置き換わるのを防げます。アップロードしても受信者用の共有リンクは作成されません。共有する場合にのみ、意図的にShare Link → Createステップを使ってください。

容量、時間、繰り返し実行

**52,428,800バイト（50 MiB）**までのファイルは1つのリクエストで送信されます。それより大きいバイナリはマルチパートセッションを使い、dosyaの応答で決まる容量のパートを順番に送信します。保存されたn8nバイナリはマルチパート用にストリームとして読み取られます。インラインのbase64データはすでにメモリ内にあります。これにより1リクエストの上限はなくなりますが、プラン、ワークスペースやキーの制限、n8nホストの容量は引き続きアップロードを制限します。

アップロード、パート、完了のリクエストはそれぞれ10分まで許容されます。通常のAPIリクエストは60秒です。安全に再試行できる一時的なリクエストは最大3回試行されます。レート制限による待機が30秒を超える場合、ノードを無期限に待たせず、ワークフローが処理できるよう報告します。長い待機にはWaitノードまたは明示的な再試行ポリシーを使ってください。

単一リクエストのアップロードでは、実行、ノード、項目、送信先、ファイル名、内容から冪等性キーを生成します。同じアップロードを再試行すると、保存された結果がdeduplicated: trueとともに返される場合があります。新しいワークフローの実行ではキーが異なるため、同じファイル名で新しいバージョンが作成される場合があります。マルチパートのパートは安全に再試行できますが、結果が不明な初期化や完了は自動で再送されません。失敗時、ノードは開いているマルチパートセッションの中止を試みます。タイムアウトした実行を再実行する前にdosyaを確認してください。タイムアウトしたからといって、ファイルが保存されていないとは限りません。

フィールドや応答の問題を解決

問題	対処
No workspace selected	Workspaceを選択するか、マッピングしたIDを修正してください。Workspace IDs start with ws_は手入力したIDが無効であることを示します。
バイナリ入力がない	ファイルを生成する前のステップを実行し、Binaryを確認してください。そのプロパティ名をInput Data Field Nameにコピーします。JSONのみの項目はアップロードできません。
dosya.dev did not accept the API key	認証情報のキーの入力間違い、期限切れ、無効化を確認し、キーを置き換えてください。
anchored at a folderに言及する403	フォルダーアンカーのないAPI対応キーを使ってください。フォルダーアンカーはWebDAV/S3で機能しますが、このRESTノードでは使えません。
その他の403、または送信先が表示されない	キーのワークスペース固定、メンバーのロール、フォルダーへのアクセスを確認してください。権限の期限切れはFile Nameを変えても解決しません。
413	実際のプラン、ワークスペース、キーのファイル容量制限を確認してください。マルチパートでも制限は解除されません。
ストレージ制限による拒否	ストレージの空き容量を確保するか、ワークスペース管理者に上限の引き上げを依頼してください。ワークスペースの上限は必ずしもプランのアップグレードで解決するものではありません。
dosya.dev did not open a multi-part upload	サービスの状態を確認してから再試行してください。問題が続く場合は、サポートに伝えるため実行の詳細を保存してください。
429	表示された待機時間に従い、ワークフローの並行数を減らすか、バッチ間にWaitを挿入してください。

実行結果

成功した各入力項目から、正しい送信先のファイルメタデータが生成され、元のバイナリと照合できます。n8n認証情報の接続を解除するかキーを無効化すると、以後のAPI使用は停止します。すでにアップロードされたファイルは、以前の実行で作成されたバージョンを含め、dosyaに残ります。

関連ガイド

• dosyaをn8nに接続
• n8nワークフローを作成