Send an Excel Extract Worksheets request with no worksheet names and no worksheet indexes, and the response comes back with every sheet in the workbook, not the first one, not an empty result, not an error. That is documented behavior, not a fallback for a missing parameter. A team building an export step that runs Extract Worksheets on a customer-uploaded workbook, expecting to pull just the tab their template looks for, can end up shipping every internal tab in that workbook downstream instead, simply because the filter fields were left blank during testing.
Extract Worksheets: union selection, empty means everything
PDF4me's Extract Worksheets endpoint (https://docs.pdf4me.com/pdf4me-api/excel/extract-worksheets/) calls this out in its own Important Facts section: names and indexes combine as a union, and leaving both empty extracts everything. The request body looks like this:
POST office/ApiV2Excel/ExcelExtractWorksheet
{
"document": { "Name": "report.xlsx" },
"docContent": "<Base64 workbook bytes>",
"extractWorksheetToExcelAction": {
"worksheetNames": [],
"worksheetIndexes": [],
"cultureName": "en-US"
}
}
With both arrays empty, every worksheet comes back keyed by name in the response. If worksheetNames is ["Summary"] and worksheetIndexes is [0], and index 0 happens to be a different sheet than Summary, the response contains both sheets, not the intersection. Name matching is case-sensitive, and because a match failure is silent rather than an outright error unless nothing at all matches, a mistyped case can quietly drop a sheet out of a multi-sheet extraction without surfacing a warning anywhere in the response.
The same union-and-empty-means-all logic holds on every platform PDF4me ships this feature to. Make's Extract Worksheets module and Zapier's Extract Worksheets action both document the identical union behavior, and so do Power Automate's Extract Worksheets action and the n8n Extract Worksheets node. Where they stop agreeing is on a detail a developer would reasonably assume travels unchanged across one vendor's own integrations: what number identifies the first worksheet.
The worksheet index that changes meaning by platform
On the REST API, worksheet indexes are 0-based. Index 0 is the first sheet. Power Automate keeps that convention exactly, its documentation stating plainly that index 0 is the first worksheet and index 1 the second, matching the API underneath it. The n8n node does the same, with its own parameter table marking Worksheet Indexes as 0-based. Two platforms, one convention.
Make and Zapier both break from that. In Make's Extract Worksheets module, the same Worksheet Indexes field is explicitly 1-based, with the documentation noting that index 1 means the first worksheet. Zapier goes further and flags the mismatch itself: its own Extract Worksheets documentation states that indexes are 1-based and adds that this is different from the zero-based indexing used in many programming languages, which is Zapier telling its own users, in its own docs, that the convention here is not the one they are used to. Index 2 means the third worksheet in one platform and the second in another for the exact same PDF4me operation.
Extract Rows: a JSON-out endpoint, not a file-out one
Extract Rows is a different endpoint from Extract Worksheets, built to pull a row and column range back as JSON rather than hand back a file. Its own REST documentation is explicit that document and fileName come back null by design, because the point of this call is structured data, not a document to pass downstream.
POST office/ApiV2Excel/ExcelExtractRows
{
"document": { "Name": "report.xlsx" },
"docContent": "<Base64 workbook bytes>",
"extractRowsToExcelAction": {
"worksheetName": "Sheet1",
"worksheetIndex": 0,
"fromRow": 0,
"toRow": -1,
"cultureName": "en-US"
}
}
The endpoint also carries options worth knowing before wiring it into a pipeline: Has Header Row controls whether the first row extracted becomes the JSON keys or gets treated as data, Exclude Hidden Rows and Exclude Hidden Columns can filter out anything hidden in the source sheet, and Export Values As Text forces every cell to a string instead of preserving numbers, dates, and booleans in their native JSON types. Row and column indexes here are 0-based on REST, and that convention carries cleanly through Power Automate and n8n as well: the Power Automate Extract Rows action documents First Row and First Column as 0-based, and the n8n Extract Rows node matches it, down to the same rule that -1 means read to the last row with data.
Here is where the two platforms that broke the worksheet-index convention diverge from each other as well. Make's Extract Rows module keeps First Row, Last Row, First Column, and Last Column all 0-based, the same as REST, even though Make's own Extract Worksheets module one page over uses 1-based worksheet indexes. Inside a single platform, one Excel action counts from zero and the neighboring one counts from one. Zapier does not split the difference the way Make does. Its Extract Rows action is 1-based for rows and columns as well as worksheets, and once again the documentation names the gap itself, noting that row 1 in the request means Excel row 1, aimed squarely at developers used to counting from zero. Of the four integration platforms, Zapier is the only one where every index in both Excel actions has shifted by one relative to the REST API underneath it.
None of this makes any single convention wrong. Row 1 meaning the first row is arguably more intuitive to a spreadsheet user than row 0 meaning the first row, and it would not be surprising if that intuition is exactly why two no-code platforms built for less technical users chose to count from one somewhere along the way. But intuitive and consistent are different qualities, and a team running the same read-a-range logic across two of these platforms is copying numbers that mean different things depending on where they land.
Merge Files: order comes from SortPosition, not array order
Merge Files sidesteps the indexing question entirely since it does not read by position, but it has its own ordering rule worth knowing before relying on it.
POST office/ApiV2Excel/ExcelMergeFiles
{
"mergeFilesToExcelAction": {
"documents": [
{ "filename": "north.xlsx", "fileContent": "<Base64>", "sortPosition": 1 },
{ "filename": "south.xlsx", "fileContent": "<Base64>", "sortPosition": 2 }
],
"outputFileName": "combined",
"cultureName": "en-US"
}
}
The Documents array does not merge in the order the array was written. It merges by SortPosition, ascending, so a request that lists file C first but assigns it SortPosition 3, while file A carries SortPosition 1, places A first in the output regardless of array order. Make's Merge Files module and the n8n Merge Files node both carry the same Sort Position field forward, and Power Automate's Merge Files action documents identical behavior through its own MergeDocument objects. Zapier's Merge Files action uses Sort Position the same way, and its documentation adds a detail worth flagging on its own: the output field shape for Merge Files is explicitly shared across Merge Files, Add Rows, Delete Rows, and other PDF4me Excel actions in Zapier, so code parsing that response should not assume every field is unique to this one operation.
Across every platform, worksheet name collisions during a merge get resolved automatically by suffixing duplicates rather than failing the request, and CSV is the one output format that only carries the first worksheet forward, since a CSV file cannot represent more than one sheet at a time. A monthly consolidation flow that merges five regional workbooks and outputs CSV for a downstream database load will silently lose four sheets worth of data unless XLSX or XLS is chosen instead.
Test the index before you trust it
The practical habit this points to is simple, and it costs one test run to build. Do not assume an index value is portable between two PDF4me integrations just because it is the same feature from the same vendor. Before wiring a row or worksheet number into a production flow, run the same request once against a known workbook with index 0 and again with index 1, note which sheet or row actually comes back on that specific platform, and treat the REST API's 0-based convention as a baseline that Power Automate and n8n happen to preserve rather than a rule every PDF4me integration follows.
Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com
Top comments (0)