Need Help with File Upload to Google Drive via API for Scale

[Jonathan_Killam]

Hello Makers,

I am looking for expert help with the final step of a Make.com scenario that integrates Google Drive’s API. The project has made significant progress, but the last piece of functionality—correctly uploading files to designated Google Drive folders—has become a persistent issue.

The Problem:

• File Creation Without Data: Files are being created in the correct folders with the right names, but they remain empty (shell files).
• Timeouts: When attempting to upload file content, the operation frequently results in a timeout.
• File Upload Process: I’ve attempted both resumable and multipart upload methods using HTTP modules, following Google’s API documentation, but neither reliably transfers the file data.

Context:

• The scenario dynamically fetches files from external URLs and needs to upload them into specific nested folders within Google Drive.
• The folder structure, file data, and paths are all generated dynamically.
• I have implemented iterators, variable mappings, and dynamic URL retrieval, and I’m confident the overall scenario logic is solid. However, the file data simply isn’t being transmitted correctly in the upload step.

Support Insights:

• Make.com support reviewed the configuration and confirmed the API requests appear to align with Google’s documentation.
• They suggested contacting Google support for further assistance. Unfortunately, as many of us know, getting meaningful help from Google support can be a challenging and often unproductive experience.

What I Need:

I’m looking for someone who can:

• Review the current scenario setup and identify why the file upload isn’t working.
• Provide corrections or optimizations for the HTTP module configuration.
• Ensure files are properly uploaded to the correct locations in Google Drive with their data intact.

I have detailed documentation of the issue, screenshots, and previous troubleshooting attempts that I can share to provide clarity on what’s been done so far. While my budget is limited, I’m open to reasonable compensation for some assistance to wrap this up.

If you’re experienced with Make.com and Google Drive API integrations and think you can help resolve this, please reach out.

Best regards,
Jonathan

P.S.
Here are previous forums posts that I have made about this project to help you further understand the complexities:
Google Drive API - Files Uploaded as Empty Shells via HTTP Module
Uploading Multiple Files from HTTP Array to Google Drive
Google Drive OAuth for Scale

[Donald_Mitchell]

Hello @Jonathan_Killam,

I’ve looked at your blueprint and it’d be very difficult to debug without actual (even if it’s test) data, but I did notice something you might want to look at…

In Value you’ve got 4 hyphens followed by 123456789 but in the Request content you’ve got 6 hyphens.

[Donald_Mitchell]

I realize now the two hyphens are supposed to prefix the boundary value, so 6 hyphens makes sense!

Anyway, the documentation says Content-Length should be added to the headers and set to the total number of bytes in the request body.

Didn’t see that in the Headers in the blueprint

Also, you’ve got the < and > characters around 126.meta.mimetype and 127.Data. Are those there during your scenario run? Can’t find a reference that calls for that syntax.

[Jonathan_Killam]

Thank you Donald,
for pointing that out! While your observation about the hyphen count was helpful, I wanted to clarify the correct usage of boundaries based on the API documentation and the adjustments I made prior to your comment.

For multipart requests, the boundary is critical for separating the metadata and file content. The documentation specifies that:

1. The boundary must start with two hyphens (--) in the header definition.
2. Within the body:

• Each section starts with the exact boundary string defined in the header, prefixed with two hyphens.
• The final boundary at the end of the request must also include two additional trailing hyphens (--) to indicate the closing of the multipart content.

I ensured that both the header and body use the boundary string consistently, adhering to these rules. This includes:

• No extra hyphens in the header definition.
• Correctly marking the beginning, separation, and closure of the multipart sections within the request body.

While the header and body definitions must match exactly, the distinction between the opening and closing boundaries (with trailing hyphens) is often a subtle source of error, so I made sure to address this. It’s always good to have a second pair of eyes, so thank you for your attention to detail! Let me know if you’ve encountered any other possible issues. I am still seeking a solution to the issues with this scenario.

[Jonathan_Killam]

I just saw your other reply. I have been trying everything under the sun, so I am not sure if I previously had the Content-Length in the header, but I just added it in there and tested it. Same results with a timeout. Same with the syntax too

[Donald_Mitchell]

Bummer, sorry to hear it!
And you were getting timeout errors before? Or just empty files? How large are these files? I assume you saw the note that they should be under about 5MB?

So I guess if you might exceed that, you’ll need to route to another path that uses resumable upload rather than multipart, but resumable would work with both so may as well build that out anyway

Also, with Content-Length header, not only does it need to be there I believe its value needs to be the actual length of the content…

[Jonathan_Killam]

I have been testing both mutipart and resumable. The results are always either a timeout or shell files uploaded into the folder. The files are well below the threshold for size.

[Donald_Mitchell]

Let’s assume all files are always going to be under 5MB.
You can try something like this…

Add a Compose a String between HTTP Get a File and HTTP Make a Request

Inside Compose a String, transfer all the contents of your HTTP Make a Request - Request Content, and also remove those angle brackets < and > like this:

Then map the result of Compose a String into the Request Content and add a Content-Length header consisting of the length of Compose a String, like this:

See if that helps at all?

[Jonathan_Killam]

No dice.

[Donald_Mitchell]

Seems like some mapping got messed up or something.
Also your boundary text changed and you’ve only got two hyphens, so did the boundary= Value change too to boundary=123456789 ?

parents might not resolve correctly either.
Can you expand on the input so we can see what went into the HTTP Make a Request module or no?

[Jonathan_Killam]

I removed the unnecessary hyphens to avoid confusion.
I am happy to show you anything you want to see minus the sensitive items like API keys, client ID & secret.

[Donald_Mitchell]

The way the built-in Google Drive app does it is in two requests.
Create the shell, then fill it with data.

The first:

POST https://www.googleapis.com/drive/v3/files

Headers:

{
    "user-agent": "Make/production",
    "authorization": "***",
    "content-type": "application/json"
}

Query String:

{
    "supportsAllDrives": true
}

Body:

{
    "name": "New_file.jpeg"
}

Response:

{
    "kind": "drive#file",
    "id": "1YeaG48jaRqFXidBhRU04XNZFxJCbk7pr",
    "name": "New_file.jpeg",
    "mimeType": "application/octet-stream"
}

Second:
PATCH https://www.googleapis.com/upload/drive/v3/files/1YeaG48jaRqFXidBhRU04XNZFxJCbk7pr

This uses the file ID from the first call

Query String:

{
    "fields": "*",
    "uploadType": "media",
    "supportsAllDrives": true
}

Body:
Binary data