Hi everyone,
I’m running into a confusing issue with binary file uploads to WordPress using the HTTP Request node, and I can’t find a clear explanation yet.
Setup
n8n Cloud
Uploading images (PNG) to WordPress via:
POST /wp-json/wp/v2/media
Authentication: WordPress API credentials
Body Content Type: n8n Binary File
Binary field: data
Headers used:
Content-Type: image/png
Content-Disposition: attachment; filename=…
Images are generated via Kie AI, downloaded from a temporary URL, and available in n8n as a valid binary (filename, size, mime-type all correct and visible).
What works
The media upload works correctly:
in a sandbox WordPress site
in other workflows
even on the same production WordPress site, but in a different workflow
Same endpoint, same credentials, same headers, same binary type.
What does NOT work
In one specific workflow, the upload t
Service unavailable – try again later
This happens:
with the same HTTP Request configuration
same credentials
same binary type (binary.data)
same image format and size
Copying the workflow to another WordPress site → it works
Using another workflow on the same site → it works
Important clarifications
This is not about posts vs pages.
It’s not caused by concurrent workflows uploading at the same time.
It’s not a missing or invalid binary (the binary is visible and downloadable in n8n).
It’s not an authentication issue.
The HTTP Request node settings are effectively identical between working and failing cases.
Why this is confusing
From the n8n side:
The binary is valid.
The request is sent correctly.
The same setup works in other workflows and environments.
But:
On the same WordPress site, one workflow succeeds and another fails,
without any visible difference in the HTTP Request node itself.
This makes it hard to understand what makes a binary upload “safe” or “unsafe” in certain workflow contexts.
Hi @Marketing_Spma !
This usually happens when the binary data is not in a clean stream state in that specific workflow, even though it looks valid in n8n.
To fix it, re-materialize the binary right before the upload (either re-download the image with “Download Binary” enabled, or pass it through a Set node with “Keep Binary Data”).
Also remove the manually set Content-Type header and let n8n infer it from the binary >> this avoids WordPress/PHP rejecting the request with a 503.