Hi n8n Community,
I am experiencing a perplexing issue while integrating Stirling-PDF (self-hosted via Docker) into my n8n workflow. I have enabled SECURITY_APIKEY for security.
The Paradox:
Successful Operation: I can successfully use the PDF-to-Word endpoint. The authentication via X-API-KEY header works perfectly, and the file is processed correctly.
Failed Operation: When I switch to the Merge PDFs endpoint (/api/v1/general/merge-pdfs), the process fails.
The Errors I encounter:
Sometimes I get a 401 Unauthorized (even though the same key works for conversion).
Other times I get a 400 Bad Request.
Frequently, the server responds that the file is “Invalid” or there is a “Processing Error”, despite the PDFs being healthy and working in other nodes.
My Workflow Setup for Merging:
Method: POST
Authentication: Header Auth with X-API-KEY.
Body Content Type: Multipart/form-data.
Body Parameters: Sending two binary files using the field name fileInput.
My Questions for the Experts:
Since the API key is valid for conversions, why does the Merge endpoint specifically struggle with authentication or return 400?
How should multiple binary files be structured in the HTTP Request node for Stirling-PDF? Should they use the same field name (fileInput), or is there a specific array/naming convention required?
Is there a specific MIME-type handling or “Content-Length” requirement for merging that differs from single-file conversion?
I would appreciate any guidance or a working example of a Stirling-PDF Merge configuration in n8n. N8n last virsion
Hi @abd2001 ,
Since the API key is valid for conversions, why does the Merge endpoint specifically struggle with authentication or return 400?
since merge-pdfs endpoint have some required body request, make sure your body request have the following details:
- fileInput: array of file pdf
- sortType: ‘orderProvided’, ‘byFileName’, ‘byDateModified’
- removeCertSign: true
- generateToc: false
looks like this:
