Page Range, Page Count, or Individual Pages: The Three Ways to Split a PDF

Say you have a 40 page contract and you need three different things out of it: pages 1 to 10 for the counterparty, every 5 pages as a separate reviewer packet, and pages 3, 12, and 27 pulled out on their own because that is where the signature blocks live. That is not one splitting problem. That is three, and PDF4me's Split PDF endpoint treats them as three separate parameters, not three separate products.

Here is what is actually going on under the hood, and why the platform you build on changes how many of those three ways you can reach.

What the endpoint actually does

The Split PDF REST endpoint is a single POST /api/v2/SplitPDF call. You send it a base64 PDF and one of four splitAction values:

• SplitAfterPage: cut once, after a page you name. Two output files, always.
• RecurringSplitAfterPage: cut every N pages. A 21 page PDF with splitActionNumber 4 comes back as six files.
• SplitSequence: cut at a list of specific pages, like [1, 3, 8].
• SplitRanges: pull out named ranges, like "1-4" or "10-21".

That fourth column, count, range, sequence, plus the simple two way cut, is the whole feature. It is worth reading the docs page's own parameter table closely, because it has a small inconsistency worth knowing about before you write code: the Required Parameters table labels the two file fields "File Content" and "File Name," but the Payload example directly underneath it, and the interactive API Tester's Split PDF page, both confirm the real JSON keys are docContent and docName. The table labels are UI-friendly aliases, not the field names your request body actually needs.

The response has its own small oddity too: the live docs page's own JSON example spells the output array key splited Documents, not "split." It is not a typo in this article. It is what the page says.

Here is a minimal request built from the verified field names, using Python's requests library:

import base64
import requests

with open("contract.pdf", "rb") as f:
    doc_content = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": doc_content,
    "docName": "contract.pdf",
    "splitAction": "SplitRanges",
    "splitRanges": "1-10",
    "fileNaming": "NameAsPerOrder",
    "async": False
}

response = requests.post(
    "https://api.pdf4me.com/api/v2/SplitPDF",
    headers={"Authorization": "YOUR_API_KEY", "Content-Type": "application/json"},
    json=payload
)

result = response.json()
# result["splited Documents"] holds the array of split PDFs

Swap splitAction to SplitSequence with a splitSequence value like [1, 3, 8] for the individual pages case, or RecurringSplitAfterPage with splitActionNumber for equal chunks. Same endpoint, same payload shape, one field changes.

Four platforms, two very different capability sets

This is the part worth building a workflow decision around, because the four platforms do not offer the same three ways to split.

REST and n8n match each other exactly. n8n's Split PDF node exposes the same four options as the REST call, Split After Page, Recurring Split After Page, Split Sequence, and Split Ranges, through one Split Action dropdown, plus its own richer output (fileSize, success, splitCount, originalFileName on top of the split files themselves). If your workflow needs to pull out pages 3, 12, and 27 in one call, or extract "10 to 21" as a named range, n8n can do it without leaving the node.

Power Automate and Zapier both cut that down to two options. Simple Split (one cut point, two output files) and Recurring Split (equal N page segments). That is it. Neither platform's Split PDF action exposes a page-range mode or a specific-page-sequence mode in its UI, full stop. If your Power Automate flow or your Zap needs to hand back "pages 3, 12, and 27" as one output, the building block for that is not on this action, at least not as documented today.

Make is the platform to read most carefully, because its own documentation page does not agree with itself. The prose at the top of the page and its "Common Questions" section describe a comma-separated, zero-indexed range notation: 0, 5, 10- creating three parts, a trailing hyphen meaning "to the end." That reads exactly like REST's SplitRanges or SplitSequence. But the actual configurable Parameter table further down the same page only offers Simple Split and Recurring Split, with a single one-based Page Number field, the same reduced shape as Power Automate and Zapier. Two different splitting models, described on the same page, and only one of them appears to be an actual configurable field. If you are building in Make, test against the live module before you assume the range notation in the prose is reachable from the UI.

So if the job is "split into equal chunks" or "cut once at page N," all four platforms handle it. If the job is "pull out this specific list of pages" or "extract this named range," you are choosing between REST, n8n, or writing around the gap on Power Automate and Zapier.

Where this actually gets used

The Power Automate docs walk through a legal review scenario that is a good stand-in for the general pattern: a 100 page contract comes in, gets Recurring Split into 10 page segments, and each segment routes to a different reviewer through an Apply to Each loop. That is the "page count" way to split, and it is the one every platform here supports.

The "page range" and "individual pages" ways show up when the output is not evenly sized. A signed contract where the main agreement is pages 1 through 10 and the schedules are pages 11 onward is a SplitRanges job, not a Recurring Split job, because the two halves are different lengths and only one of them (the schedules) needs to go to a narrower distribution list. Zapier's own docs describe exactly this contract-splitting scenario, but built on Simple Split, a single cut point, because that is the only tool the platform's Split PDF action actually gives you for it.

For jobs where you just need a handful of pages out and do not care about the rest of the document as separate files, PDF4me also has a dedicated Extract Pages endpoint, which Make's own docs point to explicitly for that narrower case. Split PDF and Extract Pages solve adjacent but different problems: one divides a document into multiple outputs, the other pulls a subset into one.

Before you build, test it live

Every one of the split action types above is easier to confirm than to guess. The Split PDF page in the interactive API Tester has a working, live form for this exact endpoint: paste a base64 PDF, pick a split action, send the request, see the actual response shape come back. It is worth noting that this specific tester page is fully functional right now, even though the API Tester's own general getting-started page still lists Split PDF under "coming soon" in its endpoint status list. The individual page works. The status blurb has not caught up.

That live check matters more than usual here, because this is a feature where four platforms genuinely diverge on what is configurable, one page contradicts itself, and a parameter table uses different field names than the payload beneath it. None of that is unusual for a mature API surface. It is just worth confirming against the real request and response before you wire a production flow around a page range you assumed was there.

Want to see the exact request/response shape before you write a line of code? The Connect to PDF4me API guide covers authentication and the base URL, and the C# sample for Split PDF on GitHub is a working reference if C# is closer to your stack than Python.

Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com