Help Needed: 400 DataError Byte Mismatch on YouTube Resumable Upload (Dropbox Source)

:bullseye: What is your goal?

I’m pivoting a workflow to handle “Long Form” video (500MB – 1GB+)I’m hitting a wall with a byte-mismatch error in an HTTP PUT request.

The Setup:

Trigger: Dropbox “Watch Files”.

Download: Dropbox “Download a File” (Module 51).

Init: HTTP POST to YouTube API uploadType=resumable. This works and returns the location URI.

The “Heavy Hauler” Step: HTTP PUT (Module 71) using the location URI, with the Body set to Raw and mapped to 51. Data.

:thinking: What is the problem & what have you tried?

Request failed with status code 400. Invalid request. There were 4897824 bytes (or more) in the request body. There should have been 4833280 bytes according to the Content-Range header.

What i have tried:Credits/Data: Account has 2.5GB data transfer and 14K credits active.

Headers: I’ve tried manually setting Content-Length (using Dropbox 40.Size) and deleting it to let Make calculate it. Both result in a 400 error.

Compression: “Request compressed content” is toggled OFF.

Timeout: Set to 300s.

MimeType: Correctly mapped from Dropbox metadata.

It seems Make is appending roughly 64KB of extra data to the binary stream during the PUT request, which causes YouTube to reject the file.

Has anyone successfully streamed 200MB+ binary data from Dropbox to YouTube’s resumable endpoint? Is there a specific way to “clean” the Dropbox data stream to ensure the byte count stays exact?

Thanks in advance!

:clipboard: Error messages or input/output bundles

DataError
Request failed with status code 400
Invalid request. There were 213974091 byte(s) (or more) in the request body. There should have been 212762624 byte(s) according to the Content-Range header.

:camera_with_flash: Screenshots (scenario flow, module settings, errors)

FYI, that ~64KB mismatch is Make’s HTTP module adding JSON wrapper overhead when you set the body to “Raw” with binary data.

YouTube’s resumable upload is strict and it validates the exact byte count in the Content-Range header, so any padding breaks it.

Don’t map the whole Data object. For example, instead of using 1.Data, you should use 1.Data.Content (That’s only an example, you need to check out what is in your module)

Run it. Open the execution and inspect what it returns. (It might be a file or content that is in bytes)

In your HTTP PUT headers, add something like:

Content-Length: {{1.Size}}

And make sure the Content-Range header uses that same 1.Size value. They have to match exactly.

If you have trouble finding the exact values or variables. Send a screenshot of the Dropbox output module (you can also download the JSON and paste it here) so I’ll know what field it is running at the moment.

Thank you so much, I thought as much it was clearly adding something. So what you’re saying is limit the size to allow for the padding. Make sure headers correlate with the same values. I’ll try that and feedback.

Exactly! Don’t try to account for the padding and just use the actual file size from Dropbox and let Make handle it.

Remember, only map 1.Data.content (the actual binary) into the PUT body, not the whole Data object then set Content-Length header to {{1.Size}} and make sure your Content-Range header also uses {{1.Size}} with same value.

Test with a smaller file first (50-100MB) to confirm it works before uploading the 1GB files.

Run it and let me know what happens. If you hit a different error or it still mismatches, send the execution output and I’ll take a look at it.

That seems to have done the trick. I have hit another 400 error due to hitting my YouTube upload quota. That suggest to me YT endpoint is seeing the file, just have to wait for quota reset.

1 Like