Instead of using the “Item” resource to find your files, use the “File” resource. This ensures the IDs returned are compatible with the Download operation.
Replace your first node:
Resource: File
Operation: List
Configure the Folder:
In the “List” operation, you can specify the folder path or ID. Since you want /Shared Documents/Dana, ensure you are targeting that specific folder.
The Output:
The id returned by Resource: File →Operation: List is the DriveItem ID.
The Download Node:
Pass this id directly into Resource: File →Operation: Download. This will now resolve the 400 Bad Request error.
If the built-in “File → List” operation doesn’t give you the exact filtering you need, you can use the Microsoft Graph API directly. This is often more reliable for deep folder structures.
Step 1: List files in the folder Use an HTTP Request node:
@dana_bida the id from Item → Get Many is the list-item id, but Download wants the driveItem id, thats your 400. easiest fix is to skip the download node entirely, the Graph children call already hands you a pre-signed download link per file, so you just GET that, no id juggling:
swap SITE_ID for the parentReference.siteId you already see in your output, reuse your existing SharePoint OAuth cred on the first node, and leave the download node’s auth on None since the url is already pre-signed. if that download link ever comes back empty (app-only auth does that), point that node at /sites/SITE_ID/drive/items/{{ $json.id }}/content with your cred attached instead.
after getting the file list, add a Filter node on file existing in the response (i.e. {{ $json.file }} is not empty) to automatically exclude subfolders from your loop, otherwise the download step will fail on folder items that sneak into the children response.