How to Merge Multiple Excel Workbooks Into One File via API

Every month-end close has the same ritual. Five regional managers each send their own spreadsheet. Someone, usually the least senior person on the finance team, opens all five, copies each tab into one master workbook, renames the sheets so they don't collide, and prays nobody fat-fingers a cell reference along the way. It's not hard work. It's just work that a computer should be doing, and isn't, because "just write a script to merge Excel files" turns out to hide more edge cases than it sounds like it does.

What happens when two source files both have a sheet named "Summary"? What happens when one file has three worksheets and another has twelve, and you only want sheet two from each? These aren't hypothetical. They're the reason a one-line "combine these files" request usually turns into a half-day of writing and testing openpyxl or EPPlus code, then maintaining it every time a source format changes.

PDF4me's Excel Merge Files API handles this as a single HTTP call. Here's exactly how it works, including the request/response shape.

The REST Endpoint

POST office/ApiV2Excel/ExcelMergeFiles
Content-Type: application/json
Authorization: Basic YOUR_BASE64_ENCODED_API_KEY

The request body, exactly as documented on the Merge Files Excel API page:

{
  "mergeFilesToExcelAction": {
    "documents": [
      { "filename": "file1.xlsx", "fileContent": "UEsDBBQABgAIAAAA..." },
      { "filename": "file2.xlsx", "fileContent": "UEsDBBQABgAIAAAA..." }
    ],
    "outputFileName": "merged.xlsx"
  }
}

A few things worth knowing before you copy this into your own code:

• fileContent is the Base64-encoded bytes of each source workbook, not a file path or URL.
• The API merges documents in array order, so East/West/Central/South ordering in a regional report comes from how you build this array, not from anything alphabetical.
• The docs page notes the casing is flexible: documents/Documents, filename/Filename, fileContent/FileContent all work.
• outputFileName is optional (defaults to merged.xlsx), and there's also an optional cultureName field (e.g. en-US) for locale-sensitive processing, not shown above since the docs example omits it too.

The response comes back as JSON with document (the merged workbook, Base64-encoded), fileName, success, and errorMessage. The docs page doesn't publish a full sample response body, so don't assume field nesting beyond those four names until you've seen a live response from your own account.

Decoding and Saving the Result (Python)

import requests
import base64
import json

api_key = "YOUR_BASE64_ENCODED_API_KEY"
url = "https://api.pdf4me.com/api/v2/office/ApiV2Excel/ExcelMergeFiles"

def encode_file(path):
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

payload = {
    "mergeFilesToExcelAction": {
        "documents": [
            {"filename": "east.xlsx", "fileContent": encode_file("east.xlsx")},
            {"filename": "west.xlsx", "fileContent": encode_file("west.xlsx")},
        ],
        "outputFileName": "merged.xlsx"
    }
}

headers = {
    "Content-Type": "application/json",
    "Authorization": f"Basic {api_key}"
}

response = requests.post(url, headers=headers, data=json.dumps(payload))
result = response.json()

if result.get("success"):
    with open("merged.xlsx", "wb") as f:
        f.write(base64.b64decode(result["document"]))
    print(f"Saved {result['fileName']}")
else:
    print(f"Merge failed: {result.get('errorMessage')}")

A note on verification: this sample uses only the request/response field names confirmed live on the docs page above. I wasn't able to cross-check against the official pdf4me-api-samples GitHub repo this session (it blocked automated fetches), so if you hit a field name mismatch in practice, the live API response from your own account is the authority, not this snippet.

Where This Gets More Capable: The No-Code Integrations

If you're not writing a custom integration, the no-code platform versions of this action expose more control than the bare REST contract above, specifically around worksheet selection and output format.

Power Automate's PDF4me Merge Excel Files action takes a list of documents where each entry can include an optional list of worksheets to merge. Leave it empty and every sheet comes along; populate it and you pull only the sheets you want, useful when someone's quarterly report has a "scratch calculations" tab you don't want shipped to the board. It also lets you pick the output format: XLSX by default, or XLS, PDF, or CSV (CSV exports only the first worksheet).

Make's PDF4me Excel to Merge Files module mirrors this with a Files array where each item carries an optional Sort Position (lower numbers merge first) and an optional Worksheets To Merge list, plus the same four output formats. Zapier's PDF4me Merge Files action automatically renames duplicate worksheet names across source files, so two files that both have a "Data" tab don't silently overwrite each other. n8n's Merge multiple Excel files node takes the same documents-plus-worksheets-plus-format shape, with the result landing as a native n8n binary object (correct Excel MIME type) so it flows straight into the next node.

Worth flagging: the REST API's own documentation doesn't describe an explicit output-format parameter the way all four integration platforms do. If you're calling REST directly, verify against your account's live response whether format selection applies there too, rather than assuming XLSX-only.

Sort Order and Worksheet Filtering, in Practice

The pattern is consistent across every platform: build a list of source files, give each an optional sort position (or rely on array order where that's all that's supported), and optionally name which worksheets you want. That's the whole decision tree, and it maps directly onto the actual common case: consolidating monthly reports where some files carry extra tabs you don't want, in an order that matters to whoever reads the output.

The duplicate-worksheet-name handling matters more than it sounds. Two regional reports both naming their summary tab "Summary" is extremely normal. A hand-rolled merge script that doesn't think about this will silently let the second "Summary" overwrite the first, and nobody notices until finance asks why the East region's numbers disappeared.

Where This Fits in a Bigger Pipeline

Merging rarely happens in isolation. It's usually one step: pull five regional exports from a shared drive, merge them, maybe convert the result to PDF for archival, then email it out. Because this is one HTTP call (or one no-code module) rather than a library you install and maintain, it slots into a Power Automate flow triggered by a new SharePoint file, a Make scenario watching a Drive folder, a Zapier zap off a form submission, or an n8n workflow chained with other document steps. PDF4me's broader Word and Excel API covers the surrounding operations too: splitting workbooks back apart, comparing versions, watermarking, password protection, and PDF-to-Office conversions.

The Honest Limits

This endpoint merges workbooks and lets you choose worksheets and order. It does not reconcile conflicting cell formulas across files, does not deduplicate rows that mean the same thing but are phrased differently, and won't catch a schema mismatch where one region's spreadsheet has an extra column the others don't. Those are data-modeling problems upstream of the merge, not inside it. What it reliably removes is the tedious part: opening N files, copying N sets of tabs, hoping you didn't drop a sheet or get the order wrong.

If you're maintaining an in-house script for this today, a quick gut check: how long would it take to add "exclude the scratch tab" as a new requirement in your existing code, versus adding one worksheetsToMerge field to a request you're already sending?

Website: pdf4me.com
Documentation: docs.pdf4me.com