Ask a developer to split a batch of merged PDFs and the first idea that comes up is usually a barcode. Print separator sheets, scan them into the stack, split on the barcode. It works, and it's the textbook answer in most document automation tutorials.
It also assumes something that's often not true: that someone controlled the scanning process in the first place. A lot of merged PDFs never went anywhere near a scanner with separator sheets. They're exports from accounting software, ten invoices concatenated into one file because that's what the export button does. They're patient records pulled from an EMR and stitched together for archival. They're legal bundles where the only structure is a line that says "EXHIBIT" before each new section. There's no barcode to detect, because nobody put one there. What there is, in every one of these cases, is text: a recurring header, a label, a keyword that shows up exactly where a new document starts.
That's the gap Split PDF by Text is built for. Instead of looking for a printed barcode, it searches the actual text content of every page for a string you specify, and treats each matching page as a split boundary. If your merged file has "Invoice Number:" printed near the top of every invoice, or "Patient Name:" at the start of every record, or "--- NEW DOCUMENT ---" inserted as a literal separator line, the engine finds every occurrence and hands back one PDF per section.
What's actually happening under the hood
The REST endpoint takes a POST request. You send the source PDF as Base64 in docContent, an output name in docName, and the string you want it to search for in text. The engine runs a full-text search across every page of the document and uses matching pages as split boundaries.
Here's a minimal Python request against the endpoint, based on the parameter names confirmed in both the live docs page and PDF4me's own Split PDF by Text sample repo:
import base64
import requests
with open("merged_invoices.pdf", "rb") as f:
doc_content = base64.b64encode(f.read()).decode("utf-8")
payload = {
"docContent": doc_content,
"docName": "output.pdf",
"text": "Invoice Number:",
"splitTextPage": "before",
"fileNaming": "NameAsPerText",
"async": True
}
headers = {
"Content-Type": "application/json",
"Authorization": "Basic YOUR_API_KEY"
}
response = requests.post(
"https://api.pdf4me.com/api/v2/SplitPdfByText",
json=payload,
headers=headers
)
One parameter decides which side of the match the split lands on. splitTextPage accepts before or after, controlling whether the new document starts on the page containing your marker text or the page right after it. A document where "Invoice Number:" sits at the top of each invoice's first page wants before, so that page stays attached to the invoice it's labeling. A document using a literal separator line like "--- NEW DOCUMENT ---" as a throwaway divider might want after, so the divider page doesn't end up glued to the following document.
The other parameter, fileNaming, decides what the split output files are called. NameAsPerOrder names them by position, while NameAsPerText names each output after the matched text itself, useful when that text is something identifying, like an invoice number. For larger files, the API also accepts an async flag; set it to true and the request returns a job ID to poll instead of blocking on a synchronous response.
One thing worth flagging directly: the marketing docs page lists the endpoint path as /api/v2/SplitByText, but PDF4me's own published sample code, across every language in the samples repo, consistently calls /api/v2/SplitPdfByText instead. The sample code is what's actually been run against the live API, so that's the path used above. Worth testing against your own account either way before you hardcode anything.
Where this actually pays off, and where it doesn't
The strongest case for text-based splitting is any document that already has a natural label baked into its layout, because someone designed it to be read by a human before you ever thought about automating it. Invoice numbers, patient names, exhibit markers, form titles: these exist because a person needed to identify the page, not because anyone anticipated splitting it programmatically later. That's exactly what makes text splitting reliable here. You're not adding new structure to the document. You're reading structure that was already there.
Where it gets shakier is anything that started life as a scanned image rather than a digitally generated PDF. Full-text search depends on the PDF actually containing a text layer, not just a picture of text. A scanned page that was never OCR'd has no searchable text for the text parameter to match against, and no amount of parameter tuning fixes that; the fix is running OCR first, not adjusting this endpoint. It's also worth testing your exact marker string against real documents before trusting it in production, because minor formatting drift, an extra space, a line break in the wrong place, a label that changes wording halfway through a scan batch, is exactly the kind of thing that looks fine in five sample files and quietly fails on file six.
It's also worth being honest about where this endpoint stops and a different one starts. If your documents already carry printed barcodes as separator markers, Split PDF by Barcode is the more deterministic tool for that job, since it doesn't depend on text formatting at all. And if you're specifically working with Swiss invoicing, Split PDF by Swiss QR is purpose-built to detect the SIX Group Swiss QR bill standard and split batch-printed invoice runs at each QR boundary. These aren't three ways of doing the same thing; they're three answers to three different questions about what marker your documents actually contain. Pick based on what's really in the file, not on which one you've heard of.
Testing it before it touches a pipeline
Before wiring this into anything automated, it's worth running a request against a real sample file and actually looking at the response, rather than assuming the parameters behave the way the description implies. The Split PDF by Text API Tester is built for exactly that: an interactive, in-browser way to send a request and inspect what comes back, including how splitTextPage behaves on your specific document, before you write a single line of integration code.
Where it plugs in
The REST endpoint is the foundation, but most teams reading this aren't calling it from raw HTTP requests, they're wiring it into whatever automation platform already runs their document workflows. In Make, the module drops into a scenario the same way any other PDF4me action does, letting you route each split output straight into the next step, whether that's a folder, a database record, or an email. Power Automate exposes the same before/after control across Microsoft 365 workflows, which matters if your merged invoices are already landing in a SharePoint library or a Teams channel. Zapier covers the same ground for teams running lighter-weight Zaps between apps that were never meant to talk to each other directly. And in n8n, the node fits into a self-hosted workflow the same way, useful if you're keeping document processing inside infrastructure you control rather than a third-party SaaS queue.
None of these change what the underlying engine does. They change where the decision to split gets made, and what happens automatically to each resulting file once it exists.
The actual test
If you're staring at a folder of merged PDFs trying to decide whether text splitting is the right tool, the test isn't "does this file have a barcode." It's simpler: open one of the files and look for a line of text that shows up, consistently, at the start of every section you want split out. If that line exists, a full-text search will find it forty times as reliably as it finds it once. If it doesn't exist, no amount of parameter tuning invents structure that was never in the document to begin with, and that's worth knowing before you build a pipeline around it rather than after.
Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com
Top comments (0)