n8n: Downloading & Uploading Binary Files (Trello Example)

Are you struggling to automate the transfer of private Trello attachments? Many users recently encountered issues when Trello restricted direct public linking, making it difficult to automatically download files like images stored within cards. If you’ve tried using automation tools like n8n and found yourself fetching HTML login pages or corrupted data instead of the actual files, you’re not alone. This common roadblock stems from Trello’s specific authentication requirements for accessing attachment binary data. But don’t worry, there’s a robust solution using n8n’s powerful HTTP Request node. This guide will walk you through the precise steps for **n8n: Downloading & Uploading Binary Files (Trello Example)**, enabling you to bypass these hurdles and seamlessly move your Trello attachments to public cloud storage like Google Drive.

The Challenge: Trello Attachments and Authentication Hurdles

Trello is an incredibly versatile tool for project management, often used to store relevant files and images directly within cards. However, a significant operational challenge arose for many automation workflows when Trello changed how attachments are accessed. Previously, some attachment URLs might have been quasi-public or easier to fetch. Now, accessing private attachments requires proper authentication, specifically via Trello’s API Key and API Token.

The core problem users face is that standard methods often fail. Simply grabbing the attachment URL from a Trello card and plugging it into an n8n HTTP Request node set to GET often results in failure. Why? Because without the correct authentication headers, Trello serves up the login page (as HTML content) or sometimes denies access, leading to corrupted or empty file downloads. Even attempting to append the API key and token as URL parameters (e.g., ?key=...&token=...) is unreliable for fetching the raw binary data needed for file operations. Furthermore, the Trello API sometimes uses 302 redirects to temporary, expiring Amazon S3 URLs for the actual download, adding another layer of complexity that generic HTTP clients might struggle with if not configured correctly.

I spent hours trying to figure out why my n8n workflow suddenly stopped downloading Trello images. It kept grabbing HTML instead of the PNG file. Turns out, the authentication method for the download URL was the key!

A Frustrated Automator (Probably)

This authentication barrier prevents straightforward workflows where you might want to, for example, automatically back up Trello card attachments to Google Drive, Dropbox, or another cloud storage service, especially if you need those files to be publicly accessible later (something Trello now prevents directly from its platform for private attachments).

Introducing n8n: Your Automation Powerhouse

This is where n8n shines. n8n (pronounced “nodemation”) is a powerful, flexible, and often self-hostable workflow automation tool. It allows you to connect various applications and services through a visual workflow editor, using nodes to perform specific actions. Unlike some simpler automation platforms, n8n provides deep control over requests and data handling, making it ideal for tackling complex scenarios like authenticated binary file downloads.

For the Trello attachment problem, n8n’s HTTP Request node is the star. It allows for fine-grained control over request methods, URLs, headers, and crucially, how the response data is processed. By configuring it correctly, we can handle Trello’s specific authentication requirements and instruct n8n to treat the response not as text or JSON, but as a binary file.

The Solution: Step-by-Step n8n Workflow

Let’s build the n8n workflow to reliably download private Trello attachments and upload them elsewhere, using Google Drive as our destination example.

Step 1: Triggering the Workflow

Every n8n workflow needs a starting point. How you trigger this depends on your specific needs:

• Trello Trigger Node (Webhook): Use the n8n Trello Trigger node configured for “Attachment Added to Card” (or similar events). This is the most automated approach, running the workflow instantly when a new attachment appears. It usually provides the Card ID and Attachment ID directly.
• Schedule Trigger Node: Run the workflow on a schedule (e.g., daily) combined with Trello nodes to fetch cards and their attachments updated since the last run.
• Manual Trigger: Simply run the workflow manually when needed, perhaps feeding it specific Card IDs or Attachment IDs.

Regardless of the trigger, the essential information you need to pass to the next steps is the Card ID and the specific Attachment ID you want to download.

Step 2: Get Attachment Info (Optional but Recommended)

While you might be tempted to jump straight to downloading, fetching the attachment’s metadata first is a good practice. It allows you to:

• Confirm you have the correct permissions to access the attachment.
• Reliably get the attachment’s original filename.
• Potentially get the direct download URL (though we might construct it anyway).
• Retrieve other useful details like MIME type or upload date.

You can achieve this using:

• n8n Trello Node: Use the “Attachment” resource and “Get” operation, providing the Card ID and Attachment ID.
• HTTP Request Node: Make a GET request to the Trello API endpoint: https://api.trello.com/1/cards/{cardId}/attachments/{attachmentId}. You’ll need to configure authentication (usually Header Auth with your API Key and Token, similar to the download step but potentially using n8n’s built-in Trello credentials might work here).

The response from this step (often a JSON object) will contain valuable information, particularly the fileName and potentially a url field. You’ll use expressions in subsequent nodes to pull data like the filename from this step’s output.

Step 3: Download Binary File (The Core Step)

This is where the magic happens. We’ll use n8n’s HTTP Request node configured precisely to handle Trello’s authentication and binary response. This is how **n8n: Downloading & Uploading Binary Files (Trello Example)** truly works.

Configure the HTTP Request node as follows:

• Method: GET
• URL: This needs to be the specific download URL for the attachment. The most reliable format is often: https://api.trello.com/1/cards/{cardId}/attachments/{attachmentId}/download/{fileName}
  • Use n8n expressions to insert the dynamic {cardId}, {attachmentId}, and {fileName}. You can get these from the trigger or the previous “Get Attachment Info” step. For example, the Card ID might be {{ $json.card.id }} and the filename {{ $node["Get Attachment Info"].json.fileName }} depending on your workflow structure.
• Authentication: Select Header Auth from the dropdown.
• Credentials for Header Auth:
  • Name (Header): Authorization
  • Value (Header): This is critical. Enter it exactly like this, replacing the placeholders with your actual Trello API Key and Token: OAuth oauth_consumer_key="YOUR_TRELLO_API_KEY", oauth_token="YOUR_TRELLO_API_TOKEN"
    • Ensure the quotes (“) are included correctly around your key and token.
    • Do not add extra spaces.
    • You can paste your keys directly (less secure) or, preferably, store them in n8n’s Credentials section and use expressions like {{ $credentials.TrelloApi.apiKey }} and {{ $credentials.TrelloApi.apiToken }} (assuming you named your credential “TrelloApi” and the fields “apiKey” and “apiToken”).
• Response Format: Set this to File. This tells n8n to expect binary data and handle it appropriately, rather than trying to parse it as JSON or text.
• Node Settings (Options section):
  • Turn OFF “Ignore SSL Issues” unless you have a very specific, understood reason (rarely needed for Trello).
  • Turn ON “Full Response” only during debugging if you need to inspect headers. For the final working workflow, it’s usually not required and can consume more memory. Leave it OFF for production.

When this node executes successfully, it won’t output JSON in the usual way. Instead, it will output an item containing a binary property, typically named data, which holds the actual file content.

Step 4: Upload Binary File (e.g., Google Drive)

Now that n8n has the binary file data in memory (in that data property), you can pass it directly to an upload node for your chosen cloud storage service. There’s no need for an intermediary “Write Binary File” node to save it to disk temporarily.

Let’s configure a Google Drive node:

• Resource: Drive
• Operation: Upload
• Binary Data?: Toggle this ON. This tells the node to look for incoming binary data rather than expecting a file path.
• Input Data Field Name: This crucial field tells the Google Drive node which property on the incoming item contains the binary file data. Since the HTTP Request node (with Response Format = File) typically outputs the binary data under the property name data, you should enter: data
  • Important: Do NOT use an n8n expression here (like {{ $json.data }}) unless you explicitly renamed the binary property in a previous node (e.g., using a Set node). Just type the literal word data.
• File Name: Use an expression to set the name of the file in Google Drive. You’ll likely want to use the original filename obtained in Step 2. Example expression: {{ $node["Get Attachment Info"].json.fileName }}
• Folder ID: Specify the ID of the Google Drive folder where you want to upload the file. You can paste the static ID directly or use an expression if it’s dynamic.
• (Optional) Options: Sometimes, for direct media uploads to Google Drive, you might need to add an option:
  • Click “Add Option”.
  • Name: uploadType
  • Value: media

Connect the output of the “Download Binary File” HTTP Request node to the input of this Google Drive node. When the workflow runs, the binary data flows directly from the download step to the upload step.

Important Notes and Debugging Tips

Getting this workflow right involves paying attention to a few key details:

• Direct Binary Transfer: Remember, you don’t need to save the file locally first using “Write Binary File”. The HTTP Request node (set to Response Format: File) passes the binary data directly to the next node if configured correctly (using the “Binary Data?” toggle and “Input Data Field Name”). This is more efficient.
• Authentication is Paramount: The exact Authorization: OAuth ... header format in the download HTTP Request node is the most common point of failure. Double-check your API Key and Token, ensure the quotes are present, and that you’ve selected “Header Auth”. Standard n8n Trello credentials often work for metadata retrieval but frequently fail for the binary download endpoint itself.
• Debugging Corrupted Files or HTML: If your uploaded file is corrupted, empty, or contains HTML (like the Trello login page), systematically check:
  • Authentication Header: Is the Authorization header value perfectly formatted? Are the keys/tokens correct and active?
  • Download URL: Is the URL pointing to the correct Trello API download endpoint, including the card ID, attachment ID, and filename? Are the IDs being inserted correctly by expressions?
  • Response Format: Is the download HTTP Request node’s “Response Format” set to File? If it’s set to JSON or String, n8n won’t handle the binary data correctly.
  • Examine Headers (Debug): Temporarily enable “Full Response” in the download node’s options. Run the workflow and inspect the output. Look at the headers property in the result. The content-type header should indicate an image (e.g., image/png, image/jpeg) or the appropriate file type, not text/html. If it’s HTML, your authentication or URL is likely wrong.
  • Input Data Field Name: Did you correctly set the “Input Data Field Name” in the upload node (e.g., Google Drive) to data (or whatever the binary property is named)?
  • n8n Execution Logs: Check the detailed execution logs in n8n for any specific error messages from the HTTP Request or Upload nodes.

Beyond Trello: Applying the Concept

While this guide focused on a Trello example, the core principles of handling binary file downloads and uploads in n8n apply to many other scenarios. You can adapt this technique to:

• Download files from other APIs requiring specific authentication headers (OAuth, Bearer Tokens, etc.).
• Fetch images or documents from internal company systems or authenticated portals.
• Upload binary data to different cloud storage providers like Amazon S3, Dropbox, OneDrive, or even custom FTP servers using the relevant n8n nodes.
• Process downloaded files within n8n before uploading (e.g., image resizing if you integrate an image processing tool or library, though this adds complexity).

The key takeaway is understanding how to configure the HTTP Request node for the specific API’s authentication mechanism and setting the “Response Format” to “File” to capture the binary data correctly.

Conclusion: Mastering Binary Files in n8n

Dealing with API authentication and binary file transfers can be tricky, as demonstrated by the common challenge with downloading private Trello attachments. However, by leveraging the flexibility of n8n and carefully configuring the HTTP Request node—specifically the authentication headers and the response format—you can build robust workflows to overcome these obstacles.

This detailed walkthrough for **n8n: Downloading & Uploading Binary Files (Trello Example)** provides a clear blueprint. Remember that precise authentication using Header Auth and setting the Response Format to ‘File’ are the critical steps for success. Once downloaded, n8n’s ability to handle binary data allows direct piping to upload nodes like Google Drive, streamlining your automation.

Stop letting API restrictions block your automation goals. With n8n, you have the tools to handle complex authentication and data types, enabling seamless integration between services like Trello and your preferred cloud storage.