Make.com Dropping Large Email Attachments? Here's How I Fixed It.

Setting up a new automation in Make.com usually feels like magic. You connect a few blocks, map some fields, and boom – things just work. This time, though, I hit a wall with something that should have been simple: taking email attachments and dropping them into Google Drive.

The Ghosting Problem: Attachments Vanish

My goal was straightforward: whenever I received an email with an attachment in a specific Gmail inbox, I wanted that attachment automatically uploaded to a designated folder in Google Drive. For small files – think PDFs, .docx files, or tiny images under 10MB – it was flawless. The automation hummed along, and files appeared exactly where they should. Beautiful.

But then came the larger files. Design assets, client videos, zipped archives, anything over, say, 20-25MB. My Make.com scenario would run, show "success" in the execution logs, and confidently declare it had processed everything. Yet, when I went to Google Drive, those larger files were nowhere to be found. Not in the target folder, not in the root, not even in the trash. They simply vanished into the digital ether. Pure ghosting.

This wasn't just annoying; it was a critical failure for a workflow I was relying on. The irony of a "no-code" tool demanding hours of debugging was not lost on me.

What I Tried (and what didn't work)

I spent a good 6-7 hours over two evenings trying to understand what was going on. Here’s the rundown of my troubleshooting journey:

1. Deep Dive into Make.com Logs: My first instinct was to check the execution history. I meticulously opened each successful run, expanded every module, and examined the input/output bundles. Every step was green. The Gmail - Get an Attachment module reported that it had successfully retrieved the attachment, even showing the correct fileSize for the missing large files. The Google Drive - Upload a File module also showed a green checkmark. This was infuriating. No errors, just no file.

2. Google Drive Sanity Checks: I double-checked the target folder ID, browsed other folders, and yes, even scoured the Google Drive trash. Nothing. It wasn't a permissions issue either, as smaller files were happily landing in the exact same spot.

3. File Size Limits Research: I dug into Make.com's documentation for any hidden global file size limits or module-specific constraints. I also checked Google Drive API limits. While both have limits, they were far beyond the 20-25MB range where my issues started. Nothing immediately pointed to a hard wall I was hitting.

4. Module Reconfiguration: I deleted and re-added both the Gmail - Get an Attachment and Google Drive - Upload a File modules. I tried different ways of mapping the file data – sometimes Make.com can be particular about whether it expects a buffer or a URL or a specific file object. No combination seemed to make a difference.

5. Different Email Sources: Just in case it was a specific email client's fault, I sent large attachments from Outlook, ProtonMail, and even another Gmail account. The result was consistently the same: small files arrived, large files disappeared.

At this point, I was about ready to give up and write a custom script, which defeated the whole purpose of using a no-code platform.

The "Aha!" Moment: Explicit HTTP Download

My breakthrough came when I started looking very closely at the Gmail - Get an Attachment module's output bundle. While it provides the data (the file content), it also provides a webContentLink – a temporary, authenticated URL where the attachment can be directly downloaded.

It hit me: maybe the direct data transfer from the Gmail - Get an Attachment module to the Google Drive - Upload a File module wasn't as robust for large files as it appeared. Perhaps Make.com's internal handling of that abstract data object had a hidden timeout or memory buffer limitation when dealing with substantial binary payloads.

The Fix:

I inserted an HTTP - Get a File module between my Gmail - Get an Attachment and Google Drive - Upload a File modules. Instead of passing the data directly from the Gmail module to Google Drive, I did this:

1. Gmail - Get an Attachment: This module still runs first, retrieving the attachment details.
2. HTTP - Get a File: In this module, I used the webContentLink from the Gmail - Get an Attachment module as the URL. This explicitly tells Make.com: "Go download this file again via a standard HTTP request."
3. Google Drive - Upload a File: Now, I mapped the Data output from the HTTP - Get a File module to the File field in Google Drive.

It looked something like this:

[
{
"name": "Gmail - Get an Attachment",
"outputs": {
"webContentLink": "https://docs.google.com/a/example.com/uc?id=XYZ&export=download",
"filename": "MyLargeFile.zip",
"fileSize": 100000000,
"mimeType": "application/zip"
// ... other outputs
}
},
{
"name": "HTTP - Get a File",
"inputs": {
"url": "{{1.webContentLink}}" // Mapped from previous Gmail module
},
"outputs": {
"data": "",
"filename": "MyLargeFile.zip"
}
},
{
"name": "Google Drive - Upload a File",
"inputs": {
"folderId": "12345",
"file": {
"data": "{{2.data}}", // Mapped from HTTP module
"filename": "{{1.filename}}"
}
}
}
]

This small change made all the difference. The HTTP - Get a File module seemed to handle the large file transfer much more reliably. I tested it with a 100MB video file, and boom – it appeared in Google Drive instantly. Every large attachment since then has worked perfectly.

It seems that while the Gmail - Get an Attachment module can get the file details, for truly large files, explicitly downloading the content via HTTP - Get a File before passing it to the next module is the more robust approach. Make.com, for all its magic, sometimes needs a little nudge to handle the heavy lifting just right. Hopefully, this saves you a few hours of head-banging!