Subject: Merge PDF Endpoint failing in Stirling-PDF (Docker) via n8n - While other endpoints work fine. Hi everyone,

Questions
1

​
​I am experiencing a persistent issue with the Merge PDFs endpoint in Stirling-PDF while using n8n. I hope someone can clarify the correct configuration.
​My Environment:
​Deployment: Both n8n and Stirling-PDF are running in separate Docker containers on the same machine.
​Authentication: SECURITY_APIKEY is enabled in the Stirling-PDF Docker environment variables.
​Network: n8n communicates with Stirling-PDF via the container name/IP and port 8080.
​The Issue:
​Success: I can successfully use the PDF to Word endpoint. The authentication (X-API-KEY header) works perfectly, and the file is processed.
​Failure: When I try to use the Merge PDFs endpoint (/api/v1/general/merge-pdfs), I get errors like 400 (Bad Request), 401 (Unauthorized), or 411 (Length Required).
​Error Message: Sometimes the response indicates “Invalid PDF” or “Missing files,” even though the binary files are correctly passed from the previous n8n node.
​Technical Details in n8n:
​Method: POST.
​Body Content Type: Multipart/form-data.
​Body Fields: I am sending two files using the field name fileInput for both (as per Stirling-PDF documentation), but it seems to fail during the merge process.
​My Question:
Since authentication works for other tasks, what is the specific requirement for the Merge endpoint in a Docker-to-Docker setup? Does Stirling-PDF expect a different field naming convention for multiple files, or a specific array structure in the multipart request?
​Any help would be greatly appreciated!

3

Hello,

**Here’s what may be actually happening.
**
When you use fileInput for both files, Stirling-PDF’s merge endpoint needs them as an array structure, not duplicate field names. Most endpoints are forgiving about this. The merge endpoint isn’t. You’re likely getting a 400 because the backend can’t parse the file array correctly, or a 411 because the Content-Length header isn’t being calculated properly when n8n constructs the multipart payload.

**The fix—and this is the critical part.
**
In your n8n HTTP Request node, you need to:

  1. Switch to raw body mode instead of relying on n8n’s automatic multipart handling. This gives you control.

  2. Construct the multipart boundary manuallyor use a proper multipart library node if n8n supports it (check their HTTP Request node docs for the latest version).

  3. Field naming: Use files (plural) as the field name, not fileInput. Stirling-PDF’s merge endpoint specifically expects this. Some versions use file[] syntax—test both.

  4. Ensure Content-Length is set explicitly. The 411 error screams missing Content-Length header. n8n sometimes drops this in Docker-to-Docker communication.

Authentication header stays the same—your X-API-KEY is fine. But add Content-Type: multipart/form-data; boundary=----YourBoundaryHere explicitly.

Docker networking detail: Since you’re container-to-container, make sure you’re using the service name (stirling-pdf:8080 if that’s your container name) in the URL, not localhost. You’re probably already doing this since PDF to Word works, but worth confirming.

One more thing—check your Stirling-PDF logs directly. Run docker logs <stirling-pdf-container-name> and look for the actual error from the merge endpoint. Sometimes it’ll say “missing field: files” or “invalid multipart structure”—that tells you exactly what to fix.

What version of Stirling-PDF are you running, and can you share a screenshot of how you’re currently configuring the body in n8n?