Body:
I’m trying to upload a PDF attachment from Gmail to an external API (Infomaniak kDrive) using the HTTP Request node with Body Content Type set to “n8n Binary File”.
The file uploads successfully (correct file size, API returns success), but the file is corrupted and cannot be opened. The file size matches the original, suggesting the binary is being sent as base64-encoded data instead of raw bytes.
@TO1 Dealing with filesystem mode can sometimes be tricky for external APIs. Have you tried setting the HTTP Request node to ‘Multipart/Form-Data’ instead of just binary? This often helps the API interpret the raw bytes correctly. Let us know if that resolves the corruption issue!
The “correct file size but corrupted content” pattern almost always means the API received base64-encoded text instead of raw bytes. When Body Content Type is “n8n Binary File”, n8n sends the raw binary stream directly - but if kDrive expects multipart, the API would likely save the literal base64 string as the file content, which matches the size but is unreadable.
Two things to try:
Switch Body Content Type to “Form Data”, add a field of type “n8n Binary File”, set the key to whatever the kDrive API docs specify (e.g. file), and set the value to attachment_0. This sends proper multipart with the correct Content-Disposition header.
Check if the kDrive API requires a specific Content-Type: application/octet-stream header - add it explicitly in the Headers section when using the raw binary body type.
Also worth testing: use a Code node before the HTTP Request to log $binary.attachment_0.mimeType and $binary.attachment_0.fileSize to confirm the binary data is intact in n8n before it reaches the HTTP node.
Before changing the workflow shape, do one byte check: a real PDF starts with %PDF-; base64 text usually starts with JVBER... and is about one third larger. Download the file kDrive stored and compare the first bytes with the Gmail binary, not only the file size.
If kDrive starts with JVBER, it received base64 text and the Form-Data/n8n Binary Data route is the right test. If it starts with %PDF- but still will not open, the next boundary is the kDrive upload endpoint/field name/content-type rather than n8n filesystem storage.
The tell here is that the file size matches but the content is corrupt, which means the bytes are being sent but re-encoded somewhere in transit, usually the binary getting mangled into a string or the wrong content type on the part. The reply above pointing you at Form-Data is the right first move.
Try this order. Switch Body Content Type to Form-Data, Parameter Type to n8n Binary Data, and set the Input Data Field Name to your exact binary property (often attachment_0 for a Gmail attachment, with no expression wrapping it). That sends a proper multipart upload, which is what most file APIs like kDrive expect, rather than raw binary in the body. If the API specifically wants raw binary rather than multipart, then instead set the body to n8n Binary File but make sure the Content-Type header matches the actual file (application/pdf), because a wrong or missing content type makes the receiver write the bytes under the wrong encoding and you get a same-size, unopenable file.
The “size matches but corrupt” symptom is almost always content-type or multipart-vs-raw, not lost data. Check what Infomaniak’s API docs say it expects, multipart form-data or a raw binary PUT, and match that exactly. Which one do their docs specify? That picks between the two fixes above.
