Merging PDFs sounds like the simplest operation in the whole document-automation catalog: take several files, stick them together, get one file back. It is, mechanically. What actually causes production incidents is not the merge itself, it's the ordering. A contract package where the signature exhibit lands before the terms it's attached to, a quarterly report where finance's numbers appear ahead of the cover page that's supposed to introduce them, an onboarding packet where page 14 of one PDF ends up sandwiched into the middle of another. None of these are merge failures. They're order failures, and order is entirely the caller's responsibility, not the API's.
PDF4me's Merge endpoint makes that responsibility explicit in a way a lot of merge tools don't bother to. There is no separate sequencing parameter, no drag-and-drop reordering step, no "sort by filename" fallback. The order you send is the order you get back, full stop.
What the endpoint actually does
The REST call is POST /api/v2/Merge. Two fields are required: docContent and docName. One optional field, async, switches large batches to asynchronous processing.
The detail worth pausing on: docContent here is an array, not a single string. Most PDF4me endpoints take one document per call. Merge is one of the few that takes several at once, and the array's index order becomes the merged document's page order. There's no separate order or sequence field sitting next to it. If your source list isn't already in the order you want, you reorder the array before the request goes out, not after.
The response is also unusual for this API: a 200 comes back as raw binary, the merged PDF itself, not a JSON envelope with a Base64 string inside it. Write the response body straight to a .pdf file. Parsing it as JSON or trying to Base64-decode it corrupts the output, and it's a mistake the docs page's own FAQ calls out directly as a common cause of "why is my merged file broken" support tickets. A 202 response, from setting async true, works the same way as PDF4me's other long-running jobs: poll the Location header on roughly a 10-second interval, per the standard pattern in the connect guide, until a 200 arrives with the finished bytes.
curl -X POST https://api.pdf4me.com/api/v2/Merge \
-H "Content-Type: application/json" \
-H "Authorization: Basic YOUR_API_KEY" \
-d '{
"docContent": ["JVBERi0x...cover...", "JVBERi0x...report...", "JVBERi0x...appendix..."],
"docName": "quarterly-pack.pdf",
"async": true
}' \
--output merged.pdf
That array order, cover, report, appendix, is the exact page order of the output. Swap two entries and the merged PDF changes with them. Nothing else in the request influences page order at all.
The part that will actually bite you: four platforms, four different shapes for the same list
Here's the finding worth building a workflow decision around, not just a syntax note. The REST engine underneath is identical everywhere. But PDF4me's own integration docs describe four structurally different ways of handing it an ordered list of files, and porting a merge step between platforms means re-learning the shape, not just the field names.
Make's Merge Multiple PDFs module takes a Files array, an Output File Name, and a third parameter none of the other three platforms document at all: Skip Protected PDF's, a boolean that lets a scenario silently skip password-protected input files instead of failing the whole batch. If your source folder sometimes contains a locked PDF, this option only exists on Make. Rebuilding the same scenario in Zapier or n8n means handling protected files yourself, upstream, because the option isn't there to flip.
Zapier's Merge Multiple PDFs action doesn't expose an array field at all in the way Make does. Its Files parameter is a list you build one entry at a time directly in the Zapier UI, mapped from a trigger or a previous step. The docs are explicit that there's no separate sort field: "arrange your trigger data or add file entries in the order you want them to appear in the merged output." Zapier's page also states plainly that PDF4me does not publish a fixed file-count ceiling for this action, so a real 20-file batch is a "test it with your actual batch size" exercise, not a documented hard limit either way.
Power Automate's action is the most structurally different of the four. Its own parameter table doesn't describe an array or a list at all. It lists fixed, numbered slots: File Contents - 1, File Contents - 2, each individually marked required, extended by clicking an Add new item button in the flow designer to get File Contents - 3, File Contents - 4, and so on. Functionally it behaves like a list once you've clicked "Add new item" enough times, but the documented shape of the parameter is numbered discrete inputs, not a single collection value the way Make and Zapier frame it.
n8n's node goes a different direction again. Its PDF Files parameter is a true array, closer to Make's framing, but it adds something none of the other three platforms document: a per-request Input Type selector, letting you choose Binary Data, Base64 String, or a public File URL as the source format for the files being merged. n8n's output is also the richest of the four: alongside the merged file, it returns fileSize, success, and inputFileCount, letting a workflow verify that the number of files it sent actually matches the number PDF4me merged, a check Make, Zapier, and Power Automate's documented outputs don't give you directly.
The one constant across all four genuinely different shapes: input order is output order, everywhere. That's the detail this article's headline is really about. Whatever the platform, however the list is built, whatever you call the parameter, the sequence you hand PDF4me is the sequence the pages come back in. Get the list order right once, and the rest of each platform's quirks (the protected-file skip on Make, the numbered slots on Power Automate, the input-type selector on n8n) are configuration details, not ordering risks.
Where this actually gets used
Contract and closing packages. Main agreement first, exhibits and schedules after, in the exact sequence a signing party or a closing attorney expects. Zapier's own workflow examples walk through exactly this: application form first, then supporting documents, assembled the moment every piece is confirmed present.
Multi-department report consolidation. Power Automate's documented workflow merges a scheduled batch of sales, finance, operations, and HR reports into one quarterly file, with a cover page inserted first so the merged document reads top to bottom the way a reviewer expects, not in whatever order the individual reports happened to be retrieved.
Folder-driven batch merges. A Make blog walkthrough covers the pattern directly: watch a cloud storage folder, iterate over whatever's in it, aggregate the results into an array, then merge, useful precisely because folder listings don't arrive pre-sorted the way a hand-built file list does.
Splitting is the deliberate inverse, not a variant. If the actual need is breaking one document into parts rather than combining several into one, that's Split PDF, a separate endpoint built for the opposite direction. And if the goal is stamping one PDF's pages on top of another's, rather than appending files end to end, that's Merge Overlay, a different operation from plain concatenation despite the similar name.
Before wiring any of this into a production flow, the API Tester's live Merge Multiple PDF Files page lets you send a real request and inspect a real response with no code, worth a five-minute pass before you write parsing logic against an assumption.
The one-line summary
Merge doesn't reorder anything, it can't, it only concatenates in whatever order it's handed. That responsibility sits entirely with the caller, and PDF4me's own four integration surfaces disagree, sometimes sharply, on what shape that ordered list should take when you build it. Learn the shape for the platform you're actually using (Make's protected-file skip, Zapier's no-sort-field list, Power Automate's numbered slots, n8n's input-type selector) rather than assuming it carries over, and the one thing that never changes, page order following input order, stops being a risk and starts being the one guarantee you can build around.
Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com
Top comments (0)