Handling per-field Content-Type in multipart/form-data HTTP Requests (n8n)
This post examines a common integration problem: sending multipart/form-data where one field must include an explicit content-type (e.g., a JSON part). The behavior is visible in Postman cURL output (using ;type=application/json) but can be tricky to reproduce in automation platforms like n8n.
What the issue is
Many back-end endpoints expect a multipart/form-data payload where one or more parts include an explicit Content-Type header (for example, a `params` field whose value is itself JSON and should be treated as `application/json`). Postman renders these requests in cURL using `--form 'params="...";type=application/json'`. Some no-code/low-code HTTP clients (including earlier n8n node implementations) do not expose a per-part content-type control in their UI, causing mismatches between manual tests and automated runs.
Why it matters to businesses
APIs that require per-part content types are common in integrations with legacy services, document ingestion, and payment/file-processing flows. If your automation platform strips or normalizes part headers, requests can fail, or downstream services may misinterpret the payload - leading to failed jobs, lost data, or reconciliation headaches. The discrepancy between manual UI execution and automated production runs increases risk and slows rollouts.
Practical options and mitigations
- Prefer native support: check whether your HTTP node supports specifying the content-type per form field; if available, use it for the JSON part.
- Workarounds: upload the JSON as a file part (set the part as a binary/file upload with application/json type) or build the multipart payload in a Function node with a low-level HTTP library and set the exact headers and boundaries.
- Testing: capture raw requests (network inspector or request logs) from both Postman and your automated run to compare boundaries and headers.
Actionable guidance for leaders
If your integrations depend on per-part content types, validate the automation platform upfront. When evaluating platforms, require an acceptance test that reproduces the multipart request exactly. Where platform limitations exist, plan for lightweight custom code (Function/Serverless) as part of the integration blueprint, and include this as a nonfunctional requirement in vendor procurement and runbooks.
Original Source
n8n Community