DEV Community: PDF4me

Draft vs High: The OCR Quality Parameter Nobody Reads the Docs For

PDF4me — Wed, 12 Aug 2026 04:57:41 +0000

Five different places document PDF4me's OCR quality setting: the REST API and four no-code platforms. Read all five pages back to back and you'll find they're not even using the same two words for it.

What the quality setting is actually deciding

A scanned page, or a PDF made from a photo of a document, is just an image. There's no text underneath it for a computer to read, search, or copy. OCR is the step that looks at each page image, works out what characters are on it, and writes that back into the file as real, selectable text.

The quality setting decides how hard that recognition pass works. A born-digital PDF that already has most of its text as a real text layer only needs a light, single pass to catch anything missing. A fully scanned or photographed document needs every page individually recognized, since none of it is real text to begin with. Pick the light option on a scan and you get an empty or garbled result. Pick the heavy option on a file that's already text and it runs the recognition anyway, on pages that didn't need it.

On PDF4me's own REST API, this is a required field in the request body: POST /api/v2/ConvertOcrPdf with qualityType set to the literal string "Draft" or "High". Draft is a fast single pass suited to normal PDFs that mostly already have a text layer. High is full per-page recognition, built for scanned or image-based documents. Pair it with ocrWhenNeeded (also a string, "true" or "false") to skip any page that's already searchable instead of reprocessing it, and language when the recognized text comes back garbled.

Five surfaces, two different vocabularies

Here's where it gets genuinely confusing, and it's the actual reason this parameter gets misconfigured more often than it should: PDF4me's own Power Automate PDF OCR action and n8n's Convert PDF to Editable PDF Using OCR node both use the exact same words as the REST API: Quality Type, set to Draft or High. Power Automate's docs even note the default is Draft if you don't specify one.

But Zapier's PDF OCR action and Make's PDF OCR module, built on the exact same underlying feature, both call the same choice Standard or Expert instead. Standard for normal PDFs, Expert for scanned or photographed documents. Same decision, same two options, different pair of words, on two of the five surfaces that expose it.

Surface	Parameter name	Values	Docs page
REST API	`qualityType`	Draft / High	ConvertOcrPdf
Power Automate	Quality Type	Draft / High (default: Draft)	PDF OCR action
n8n	Quality Type	Draft / High (response schema also lists "Archival")	Convert PDF to Editable PDF Using OCR
Zapier	Quality Type	Standard / Expert	PDF OCR - Searchable Document
Make	Quality Type	Standard / Expert	PDF OCR module

So if you've automated this feature on more than one platform, there's a real chance you've been reading two completely different vocabularies for the same setting without realizing they map onto each other. A team that builds the Power Automate flow and hands the Zapier version to someone else, or vice versa, can easily lose that connection entirely.

There's a third wrinkle worth knowing about if you're on n8n specifically: its own documented output schema lists the possible values that come back in the response as "Draft", "High", and Archival, even though the parameter description itself only mentions Draft and High as the choices you can set. Whether Archival is a real third quality tier or just a stray value from a shared internal schema isn't something the parameter table itself explains.

The other setting worth knowing about: OCR Only When Needed

Every one of these five surfaces also exposes a second, related toggle: ocrWhenNeeded on the REST API, OCR Only When Needed on Power Automate and n8n. Set it on and the engine checks each page before processing, skipping any page that already has selectable text and only running recognition on the pages that are actually images. This matters most on hybrid documents: a contract that was born digital, printed, signed by hand, and rescanned. Most of that file is still real text. Only the signature page, or a handwritten margin note, became image data. Turning this on means you don't have to choose one setting for the whole document, the engine makes that call per page.

The language parameter isn't formatted the same way twice either

If the recognized text comes back garbled, every one of these five surfaces lets you tell the engine what language to expect. What they don't agree on is the format. The REST API's own sample payload and n8n's parameter example both use the full language name, "English". Power Automate's example uses a two-letter code, en. Make's parameter table lists three-letter codes: eng, deu, fra, spa, ita, por. Copy a value from one platform's documentation into another platform's field and there's a real chance it silently fails to match, or falls back to auto-detection instead of doing what you asked. Always check the example value on the specific page you're building against, not the platform you happen to remember from last time.

Calling it directly: a live-verified request

Here's the exact request shape, straight from PDF4me's own docs page for ConvertOcrPdf, adapted into Python with requests:

import base64
import requests

API_KEY = "your-pdf4me-api-key"
URL = "https://api.pdf4me.com/api/v2/ConvertOcrPdf"

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

payload = {
    "docContent": doc_content,
    "docName": "scanned-contract.pdf",
    "qualityType": "High",
    "ocrWhenNeeded": "true",
    "language": "English",
    "outputFormat": "true",
    "isAsync": True,
}

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

response = requests.post(URL, json=payload, headers=headers)

if response.status_code == 200:
    result = response.json()
    with open("searchable.pdf", "wb") as out:
        out.write(base64.b64decode(result["docContent"]))
elif response.status_code == 202:
    # Large scan: poll the Location URL with the same Authorization header
    poll_url = response.headers["Location"]
    print(f"Processing async, poll: {poll_url}")

A few things worth calling out about this payload, all live-verified against the current docs page rather than assumed: ocrWhenNeeded and outputFormat are sent as the strings "true"/"false", not JSON booleans, while isAsync is a real boolean. Mixing those two types up is a documented, common cause of 400 errors. outputFormat is required, but the docs page itself doesn't explain what it controls beyond noting it's sent as "true" in the official samples, worth flagging rather than guessing at. The official samples also include a mergeAllSheets boolean field on this endpoint, whose purpose isn't clearly documented for a PDF-in, PDF-out OCR action either, exactly the kind of parameter that's easy to skip past without reading.

For Python, C#, Java, JavaScript, and Salesforce reference implementations, PDF4me publishes official samples alongside the docs page itself.

When to reach for the heavier setting even on a file that looks fine

The trap isn't obviously scanned documents, most people get those right by instinct. It's the hybrid case above: a file that looks like a normal PDF at a glance but has had part of its content replaced by a scanned or photographed page at some point. If a document has passed through a printer, a scanner, a fax machine, or a phone camera at any point in its life, even once, treat it as a High (or Expert) candidate. If it has only ever existed as a digital file, the lighter setting gives you the same result while skipping the recognition step entirely. When your pipeline handles a mixed batch of both, defaulting to the heavier setting is the safer call, since running it on a file that doesn't need it doesn't change the outcome, it just also performs the recognition pass on a file that didn't need it.

A checklist worth keeping next to your workflow

Before wiring up OCR in any of these five places, it's worth asking one question: has this file, or any part of it, ever touched a printer, a scanner, a fax machine, or a camera? If the answer is yes, or even maybe, reach for the heavier quality setting, whichever pair of words your platform happens to use for it. Turn on the skip-already-searchable-pages toggle so the engine isn't reprocessing text that's already there. And if the output looks garbled afterward, check the language parameter, and double-check the exact format that specific platform's own docs page expects, before assuming the OCR itself failed.

Whether you're calling the REST API directly, or building on Make, Power Automate, Zapier, or n8n, you can also test the REST endpoint interactively, with a real file, through the API Tester before wiring it into anything.

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

Blank Pages Are a Data Quality Problem Before They're a Design Problem

PDF4me — Tue, 11 Aug 2026 11:13:07 +0000

A scanner inserts a blank sheet between every duplex-scanned document in a batch. A fax gateway drops a blank cover page in front of every inbound PDF. A mail merge leaves a trailing empty page at the end of a contract because the last section happened to end exactly on a page break. None of that is a formatting problem. It's a data quality problem, because every automated step downstream of that PDF treats a page as a unit of meaning, and a blank page is a unit of nothing.

Run OCR across it and you pay for a page with no text to extract. Run an AI parser across it and you get a document object with empty fields, or worse, a parser that silently treats the blank page as the start of a new record. Split the file by page count or route it by page index and the blank page throws off every number after it. None of these are edge cases. They're the default outcome of feeding real-world scanned or merged PDFs into a pipeline that assumes every page carries content.

Why "just skip it visually" doesn't scale

At one document, a blank page is nothing, you glance at it, you move on. At the batch sizes automation actually exists for, hundreds of scanned intake forms, thousands of merged invoices, that glance becomes a full-time job nobody has. The fix isn't a person paging through PDFs looking for empty sheets. It's a step in the pipeline that detects and removes them before anything else runs.

PDF4me's Delete Blank Pages REST endpoint (POST /api/v2/DeleteBlankPages) does exactly that: it scans a PDF, identifies pages that match your definition of blank, and returns the file with those pages removed.

"Blank" is a choice, not a single definition

A page that's truly, completely empty, no text, no image, nothing, is the easy case. The harder case, and the far more common one in real scanned batches, is a page that carries something: a scanned photo or logo with no text on it, or a page of body text with no image. Whether either of those counts as "blank" depends entirely on what your pipeline actually needs gone.

That's what the endpoint's deletePageOption parameter controls, a string set to one of three values:

NoTextNoImages removes only pages with neither text nor an image present, the strictest, most conservative definition of blank.
NoText removes any page with no text content, even if it has an image on it, useful when a pipeline only cares about pages with readable text.
NoImages removes any page with no image, even if it has text, the mirror case for a pipeline that only cares about pages carrying visual content.

None of these is more correct than the others. The right one depends on which kind of near-empty page your specific documents produce.

Where this belongs in a pipeline, and where it doesn't

Blank-page removal is a cleanup step, not an extraction step, which means it belongs early: before OCR runs, before an AI parser sees the file, before anything splits the PDF by page count, page index, or a repeating text or barcode marker. Every one of those downstream steps works better, and cheaper, on a PDF where every remaining page is actually worth processing.

It's worth being clear about what this endpoint doesn't do, too. It detects blank pages automatically based on the option you choose, it doesn't remove pages you name explicitly. If you already know page 3 and page 7 need to go, Delete Pages is the right tool, direct page targeting, not content-based detection. The two solve different problems: one answers "which pages are empty," the other answers "which pages did I already decide to remove."

Calling it directly

Here's a working Python example against the raw REST API, adapted from PDF4me's official sample repository, live-verified against the docs page's own Payload and Parameters sections:

import base64
import requests
import json

api_key = "get the API key from https://dev.pdf4me.com/dashboard/#/api-keys"
url = "https://api.pdf4me.com/api/v2/DeleteBlankPages"

with open("sample.pdf", "rb") as file:
    pdf_base64 = base64.b64encode(file.read()).decode("utf-8")

payload = {
    "docContent": pdf_base64,
    "docName": "output.pdf",
    "deletePageOption": "NoTextNoImages",  # or "NoText", "NoImages"
    "async": True
}

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

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

if response.status_code == 200:
    # Synchronous success, cleaned PDF returned immediately
    with open("output.pdf", "wb") as f:
        f.write(response.content)
elif response.status_code == 202:
    # Larger files process asynchronously, poll using the returned jobId
    job_id = response.json().get("jobId")
    print(f"Processing async, job ID: {job_id}")

Two things worth calling out. First, deletePageOption is required, there's no default, you have to pick one of the three values explicitly every time. Second, don't assume every response is synchronous: larger files can come back as 202 Accepted with a job ID instead of the finished PDF, meaning your integration needs a polling step rather than treating every call as instant.

Running it without hand-rolling REST calls

Building directly against the API, the Connect to the PDF4me V2 API guide covers authentication, the base URL, and the request and response shape every PDF4me endpoint follows, DeleteBlankPages included.

Most teams aren't writing raw REST calls for this, though, they're wiring it into whichever automation platform already runs their intake pipeline:

Power Automate exposes blank-page removal as a step you can drop directly into a Microsoft 365 flow: a scanned document lands in a SharePoint library or an email attachment, the flow strips the blank pages, and whatever runs next only ever sees pages with actual content.

n8n carries the same detection-and-removal logic into a self-hosted or cloud n8n workflow, useful for teams running document automation on infrastructure they control rather than a third-party SaaS platform.

Neither Make nor Zapier currently has a dedicated module or action for this specific endpoint. If your pipeline runs on either, the REST API above is the direct path until that changes.

Before wiring this into any of the above, the Delete Blank Pages page in PDF4me's API Tester lets you upload a real file from your own batch, switch between the three delete options, and see exactly which pages get flagged under each one, interactively, in the browser, with no workflow built yet.

Where this needs judgment, not just a default

NoTextNoImages is the comprehensive option, and it's tempting to reach for it every time since it sounds like the thorough choice. It isn't always the right one. A page carrying only a faint letterhead image with no text, or only a stamped date with no image, survives NoTextNoImages untouched because it has something, even though a human reviewing the batch might call it blank too. Getting the removal you actually want means picking the option that matches what "blank" means for your specific documents, not defaulting to the strictest-sounding name. There's no way to know which option is right without testing against a real sample from your own batch first.

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

Splitting a PDF by the text on the page, not a barcode you don't have

PDF4me — Mon, 10 Aug 2026 12:53:25 +0000

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

HTML Headers and Footers: Styling PDF Margins With CSS Instead of a PDF Library

PDF4me — Sat, 08 Aug 2026 06:15:14 +0000

The instinct, the moment a ticket says "add our logo and a confidentiality line to every page," is to reach for a PDF manipulation library. Pull in iText, or PDFBox, or pdf-lib. Calculate x and y coordinates by hand. Draw text at a fixed position, in a fixed font, at a fixed size, and hope the next design change does not mean recalculating every coordinate again. That instinct is a leftover from a world where the only way to put content in a PDF's margin was to draw it there, pixel by pixel, in a language built for placing shapes on a page, not for laying out a header.

The header and footer area of a PDF is margin space, and margin space is exactly what CSS was built to lay out. The alternative to a drawing API is not a bigger drawing API. It is not touching page coordinates at all.

What the endpoint actually takes

PDF4me's Add HTML Header Footer to PDF endpoint is a single POST /api/v2/AddHtmlHeaderFooter call. Four fields are required: docName, the output filename; docContent, the Base64-encoded source PDF; htmlContent, a plain HTML string with inline CSS (not Base64-encoded, unlike the document itself); and location, set to Header, Footer, or Both.

That htmlContent field is the whole point. It is not a template reference or a design-tool export. It is a string like:

<div style="text-align: center; font-family: Arial; font-size: 12px; color: #666;">Confidential, Internal Use Only</div>

Bold text, colored text, a logo pulled in as an embedded image, multi-column layout inside the header block, all of it is standard CSS applied to standard HTML, the same skills a frontend developer already has, applied to a part of a PDF that used to require learning a completely different, PDF-specific drawing model.

Positioning does not require coordinate math either. marginLeft, marginRight, marginTop, and marginBottom are optional pixel values that reserve the space the header or footer content renders into, and skipFirstPage excludes the very first page, useful for cover sheets that should not carry a repeated banner. pages controls which pages get the treatment at all: an empty string for every page, "1" for a single page, "1,3,5" for specific pages, "2-5" for a range, or "1,3,7-10" for a mix of both. Everything runs synchronously by default and returns the finished PDF as Base64 docContent in the response body; setting async to true switches to a 202 response with a polling Location header instead, which matters more once this is numbering hundreds of documents overnight than one file a user is waiting on.

In code

The request is one HTTP call. Reading the source PDF, Base64-encoding it, and sending the styled HTML string is the entire client-side job:

import base64
import time
import requests

API_KEY = "YOUR_API_KEY"  # Base64-encoded key from the PDF4me dashboard
ENDPOINT = "https://api.pdf4me.com/api/v2/AddHtmlHeaderFooter"

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

payload = {
    "docName": "report.pdf",
    "docContent": doc_content,
    "htmlContent": "<div style='text-align:center;font-family:Arial;font-size:11px;color:#666;'>Confidential, Internal Use Only</div>",
    "location": "Footer",
    "pages": "",
    "skipFirstPage": True,
    "marginBottom": 40.0,
    "async": False
}

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

response = requests.post(ENDPOINT, json=payload, headers=headers)

if response.status_code == 200:
    result = response.json()
    pdf_bytes = base64.b64decode(result["docContent"])
    with open("report-branded.pdf", "wb") as out:
        out.write(pdf_bytes)
elif response.status_code == 202:
    poll_url = response.headers["Location"]
    while True:
        poll = requests.get(poll_url, headers=headers)
        if poll.status_code == 200:
            pdf_bytes = base64.b64decode(poll.json()["docContent"])
            with open("report-branded.pdf", "wb") as out:
                out.write(pdf_bytes)
            break
        time.sleep(2)

skipFirstPage and marginBottom above are the two fields doing the actual layout work: the margin reserves 40 pixels of footer space, and skipping the first page keeps a cover sheet clean. Swap location to "Header" or "Both" and the same shape of request adds a header block, a footer block, or both in one call.

Where this stops being a library problem

A PDF manipulation library treats a header the same way it treats every other piece of content on the page: a shape or a text run placed at an absolute coordinate, styled through that library's own API surface, which is never quite the same surface twice across libraries or languages. Move to a different library, or a different language's port of the same library, and the styling code gets rewritten from scratch, because "bold, 10pt, right-aligned, in a specific shade of grey" means something different in every drawing API.

CSS does not have that problem, because CSS is not a PDF concept. font-weight: bold, text-align: right, color: #666666, these mean the same thing whether the HTML string is built in C#, Python, JavaScript, or Salesforce Apex, because none of those languages are the thing interpreting the styling. The rendering happens on PDF4me's side, once the request lands, so the calling code only ever needs to produce a string. That is a meaningfully smaller job than producing correct calls into a page-drawing API, and it is a job most backend teams already have the skills for without hiring for it.

The one thing this endpoint is not

PDF4me also has a dedicated Add Margin to PDF endpoint, and it is worth being precise about what separates the two, because they sound related and solve different problems. Add Margin takes marginLeft, marginRight, marginTop, and marginBottom in millimeters, extends the page canvas by that amount, and pushes the existing content inward. What lands in that new space is nothing. It is blank. The endpoint's job is to make room, not to fill it.

Add HTML Header Footer starts from the opposite assumption: there is already margin space at the top or bottom of the page, or marginTop/marginBottom on this endpoint reserve it, and the job is putting styled, meaningful content into that space. One endpoint creates emptiness. The other fills it. A workflow that needs both, more room at the top of the page and a styled banner inside that room, calls Add Margin first and Add Header Footer second, not one endpoint standing in for the other.

There is a third related endpoint worth knowing about if the entire ask is a page number and nothing else: Add Page Number to PDF handles that specific case directly, with its own alignment and format parameters, no HTML string required. If the number needs to sit inside a larger designed header alongside a logo or a document title, Add HTML Header Footer is still the right tool. If a number in the corner is the entire requirement, the dedicated endpoint is fewer parameters for the same result.

Testing the HTML before it hits a pipeline

Because htmlContent is a plain string built by application code, it is worth confirming the rendered output looks right before that string generation gets buried inside a workflow step nobody reopens for months. The API Tester runs this exact endpoint in the browser: upload a PDF, paste in the HTML and CSS, see the rendered result immediately, adjust the styling, try again. That loop, write CSS, see it rendered on an actual page, is a much shorter feedback cycle than deploying a change to a scheduled job and waiting for the next run to check whether the logo is centered.

Full code samples covering this endpoint, starting with C#, are maintained in the pdf4me-api-samples repository alongside the documentation itself.

Same endpoint, four ways into a workflow

The REST call is the mechanism. Most teams reach it through whichever automation platform already runs the rest of their document pipeline.

Power Automate exposes this as a connector action inside a Flow, so a styled header lands on a generated report the same step it gets produced, no separate branded-template maintenance. See Add HTML Header Footer to PDF in Power Automate.

Zapier wires the same fields into a Zap step, useful for branding a document the moment it lands from a form submission or a CRM export. See Add HTML Header Footer to PDF in Zapier.

Make does it as a module inside a scenario, typically placed right after a merge or convert step, so the finished, assembled document gets the header rather than each source file separately. See Add HTML Header Footer to PDF in Make.

n8n treats it as a node, which fits naturally into a self-hosted or code-adjacent pipeline where the HTML string itself might be built by an earlier code node before this one applies it. See Add HTML Header Footer to PDF in n8n.

Across all four, the underlying contract matches the REST call exactly: the same htmlContent, location, margins, and page-targeting options, exposed as connector fields instead of JSON keys. HTML and CSS validated once in the API Tester carries over unchanged into whichever platform actually runs the automation.

What this does not replace

This endpoint styles a header or footer block. It is not a full page-layout engine, and it is not a substitute for a PDF library on tasks that actually need one, precise multi-page table layout, form field placement, or complex vector graphics inside the document body itself are still library territory, or a different PDF4me endpoint's job entirely. The claim here is narrower and more honest than "never touch a PDF library again": for the specific, extremely common job of putting a styled banner, a logo, or a repeating line of text into the margin of every page, HTML and CSS already describe that layout better than a drawing API does, and reaching for the heavier tool for that one job is solving a smaller problem with a bigger hammer than it needs.

The next time a ticket asks for a branded header across a batch of generated PDFs, that is markup and a POST request, not a coordinate system to relearn.

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

Numbering Pages the Way Your Print Vendor Actually Wants Them

PDF4me — Wed, 05 Aug 2026 11:11:24 +0000

A print vendor's spec sheet does not say "add page numbers." It says something like: bottom center, format "# of {1}", 12pt, skip the cover page, 10mm margin from the bottom edge. Miss any one of those and the file bounces back with a rejection note, not a phone call explaining what to fix.

That is the part page numbering tutorials skip. Adding a number to a PDF is not the hard part. Matching an exact, often oddly specific format that someone else defined, without touching the rest of the document's layout, is the actual job. Legal briefs want "- # -". Academic submissions want "Page # of {1}" top right. Some enterprise templates skip the first page entirely because it is a cover sheet. A page numbering tool that only prints "1, 2, 3" in the corner does not solve any of these, because none of them define what "properly numbered" means the same way.

What the API actually controls

PDF4me's Add Page Number to PDF endpoint is a single POST /api/v2/AddPageNumber call. You send Base64-encoded PDF content and get Base64-encoded PDF content back, with the numbering already stamped in. Everything a print spec would ask for maps to a real parameter, not a workaround.

The format itself is controlled by two placeholders inside a pageNumberFormat string: # for the current page number and {1} for the total page count. That is enough to reproduce most of what shows up on a real spec sheet:

"# of {1}" renders as 1 of 10, 2 of 10, 3 of 10
"Page #" renders as Page 1, Page 2, Page 3
"# / {1}" renders as 1 / 10, 2 / 10, 3 / 10
"- # -" renders as - 1 -, - 2 -, - 3 -
"[#/{1}]" renders as [1/10], [2/10], [3/10]
"(#)" renders as (1), (2), (3)

Positioning is two required fields, alignX (left, center, right) and alignY (top, middle, bottom), so "bottom center" or "top right" is a direct instruction, not a guess involving pixel coordinates. If the spec gets more specific than that, marginXinMM and marginYinMM set the exact offset from the edge in millimeters, each accepting a 0-100 range.

Styling covers the three things a vendor spec usually cares about: fontSize (8-72), isBold, and isItalic. There is no font-family parameter, so if a spec calls for a specific typeface on the page numbers themselves, that is outside what this endpoint controls. Size, weight, and italics are what's available, and for the overwhelming majority of numbering requirements that is the whole ask anyway.

The one option that solves a genuinely common annoyance on its own: skipFirstPage. Set it to true and page 1 (the cover, the title page) gets no number stamped on it at all, while the rest of the document numbers normally. No manual splitting the document into "cover" and "body" first.

What a vendor spec turns into, in practice

Take a real example: a legal brief spec asking for "- # -" centered at the bottom of every page, 12pt, 10mm from the bottom edge, numbering starting on the first page (no cover to skip). That translates directly into the required and optional fields, nothing left to interpret:

{
  "docName": "brief.pdf",
  "docContent": "<base64 PDF>",
  "pageNumberFormat": "- # -",
  "alignX": "center",
  "alignY": "bottom",
  "marginYinMM": 10,
  "fontSize": 12,
  "skipFirstPage": false
}

Swap pageNumberFormat to "Page # of {1}", alignX to "right", and skipFirstPage to true, and the same call now matches an academic submission spec with a title page instead. Nothing about the request structure changes between the two, only the values, which is what makes this the kind of thing worth automating once rather than handling by hand every time a new document type shows up. Full runnable code samples, starting with C#, are maintained in the pdf4me-api-samples repository alongside the endpoint's own documentation.

Async for volume

Everything above runs synchronously by default and returns a 200 with the numbered PDF immediately. For high-volume runs, set async to true and the API returns a 202 with a Location header instead. Poll that URL until it returns 200; the response body is the same shape either way: docName and a Base64 docContent. For a workflow numbering hundreds of report exports overnight rather than one document a user is waiting on, that distinction matters more than it looks like on paper.

Where this sits next to header/footer stamping

PDF4me also has a dedicated Add HTML Header/Footer to PDF endpoint that supports page number variables inside a broader HTML-formatted header or footer, alongside logos, dates, or other repeating content. If page numbers are the only thing being added, the dedicated Add Page Number endpoint above is the more direct route: fewer parameters, no HTML to construct. If the number needs to live inside a designed header or footer block with other elements around it, that's the header/footer endpoint's job instead. Worth knowing both exist before building a header/footer template just to get a number in the corner.

Testing a format before it hits a pipeline

Before wiring any of this into an automated workflow, it is worth confirming the exact format string against a sample PDF first. The API Tester runs the Add Page Number endpoint directly in the browser: upload a file, set the parameters, see the numbered result, without writing a line of integration code yet. That is the fastest way to confirm "# of {1}" bottom center at 10mm margin is actually what a spec sheet means before that logic gets buried inside a Flow, a Zap, or a scenario.

Same endpoint, four ways into a workflow

The REST endpoint is the mechanism; most teams reach it through whichever automation platform they already run everything else on.

Power Automate exposes this as a connector action inside a Flow, so page numbering becomes one more step after a document generation or approval action, with no separate script to maintain. See Add Page Numbers to PDF in Power Automate.

Zapier wires the same parameters into a Zap step, useful for numbering documents the moment they land from a form submission, a CRM export, or another connected app. See Add Page Numbers to PDF in Zapier.

Make does it as a module inside a scenario, which is where this tends to sit well downstream of a merge or convert step, numbering the final assembled document rather than each source file separately. See Add Page Numbers to PDF in Make.

n8n treats it as a node, which fits a self-hosted or code-adjacent pipeline where page numbering is one node between a document-generation step and wherever the finished file gets delivered. See Add Page Number to PDF in n8n.

Across all four, the underlying contract is identical to the REST call: the same pageNumberFormat, alignX/alignY, margins, and skipFirstPage options, just exposed as connector fields instead of JSON keys. A format string validated once in the API Tester carries over exactly as-is into whichever platform actually runs the workflow.

What this does not do

It stamps a number in a fixed format, position, and style, consistently across a document. It does not do mixed numbering schemes within a single file (roman numerals for a front-matter section, then 1, 2, 3 for the body, as some formal print specs require), and there is no font-family control beyond size, bold, and italic. There is also no way to restart the count partway through a document or offset the starting number away from 1, based on the documented parameter table; if a spec calls for either of those, that request sits outside this endpoint's scope.

None of that makes it a smaller tool than it looks like at first. It makes it a more honest one. A single-purpose endpoint that takes six or seven parameters and reliably produces one specific, well-defined output is easier to build a pipeline around than a page-layout engine trying to do everything a design tool does. For the common case, a document that just needs consistent, correctly formatted page numbers wherever a spec says they should sit, that's exactly the scope of the job, and worth building for that scope rather than something heavier.

The next time a print vendor's spec sheet lists an exact page number format, position, and margin, that is a parameter list, not a design problem.

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

A PDF a Human Reads and a Machine Parses at the Same Time: How PDF4me Builds ZUGFeRD E-Invoices

PDF4me — Mon, 03 Aug 2026 09:37:16 +0000

Picture the scenario: your invoicing pipeline generates a clean, branded PDF for a German B2B customer. It looks right. It would print fine, email fine, and satisfy anyone who opens it by hand. Then it bounces, because since January 1, 2025, that customer is legally required to receive invoices in a format their software can parse without a human retyping the totals. A pretty PDF isn't enough anymore, and honestly, for a machine, it never really was the point.

The part that surprises people who haven't dealt with this yet: the mandate doesn't force you to give up the human-readable PDF. It just requires that PDF to carry a second, structured version of itself, riding along inside it. That format is called ZUGFeRD, with an internationally aligned sibling called Factur-X.

If you've never had to build one, it's worth understanding the mechanics before the code, because it's a genuinely clever piece of engineering, not just a compliance checkbox. So how does a single file manage to be both a human-readable invoice and a machine-parseable one at once?

What a ZUGFeRD invoice actually is

Open a ZUGFeRD invoice in Adobe Acrobat or any PDF viewer and you see a normal invoice: logo, line items, totals, payment terms, nothing unusual. But embedded inside that same file, in its attachments, sits an XML document carrying the exact same invoice data in structured, typed form: invoice number, line items, tax rates, totals, every field an accounting system needs, tagged rather than buried in a paragraph a parser has to guess at.

The container format making this possible is PDF/A-3, the only PDF/A variant that permits attachments in any file format while still meeting the archival standard's long-term readability requirements. PDF/A-1 forbids embedded attachments outright, and PDF/A-2 allows embedded files only when those files are themselves PDF/A compliant; PDF/A-3 lifted that restriction to any format, which is exactly what lets an XML invoice ride along, and why every ZUGFeRD file you'll open is, underneath, a PDF/A-3b document with an XML file riding inside it.

The embedded XML follows EN 16931, the EU's semantic data model for electronic invoices, with Germany's own XRechnung profile layered on top for domestic traffic. ZUGFeRD has shipped several versions (the 1.0 line through the current 2.x releases), each defining conformance levels, typically BASIC, COMFORT, EXTENDED, and the EN16931-aligned and XRECHNUNG profiles, trading structural strictness for how much invoice detail gets exposed to the machine-readable layer.

This matters most directly for two kinds of teams: anyone generating outbound invoices for German business customers, and anyone receiving invoices who needs to parse the embedded XML straight into an ERP or accounting system instead of manually retyping totals off a PDF.

The two REST primitives underneath it

Strip the standard's name away and ZUGFeRD generation is two REST calls chained together. First, Create PDF/A converts the visible invoice into PDF/A-3b, one of eight conformance levels the endpoint supports (PDF/A-1b, PDF/A-1a, PDF/A-2b, PDF/A-2u, PDF/A-2a, PDF/A-3b, PDF/A-3u, PDF/A-3a). Second, Add Attachment to PDF embeds the invoice XML inside that PDF/A-3 shell as a file attachment, the same mechanism you'd use to attach a spreadsheet to a report, just pointed at an XML payload instead. The endpoint's own schema makes this concrete: alongside the top-level docContent and docName for the base PDF, an attachments array holds one object per file to embed, each carrying its own docName (the attachment's filename as it appears inside the PDF, typically invoice-data.xml) and docContent (that file's own Base64 content).

Here's what that looks like live-verified against docs.pdf4me.com, chained end to end:

import requests
import base64

API_KEY = "YOUR_API_KEY"  # Base64-encoded, per PDF4me's Basic auth convention
headers = {
    "Authorization": f"Basic {API_KEY}",
    "Content-Type": "application/json",
}

# Step 1: convert the invoice PDF to PDF/A-3b
with open("invoice.pdf", "rb") as f:
    pdf_b64 = base64.b64encode(f.read()).decode()

pdfa_payload = {
    "docContent": pdf_b64,
    "docName": "invoice",
    "compliance": "PdfA3b",
    "allowUpgrade": True,
    "allowDowngrade": True,
}
pdfa_resp = requests.post(
    "https://api.pdf4me.com/api/v2/PdfA", json=pdfa_payload, headers=headers
).json()

# Step 2: embed the invoice XML inside the PDF/A-3b shell
with open("invoice-data.xml", "rb") as f:
    xml_b64 = base64.b64encode(f.read()).decode()

attach_payload = {
    "docContent": pdfa_resp["docContent"],
    "docName": "invoice.pdf",
    "attachments": [
        {"docName": "invoice-data.xml", "docContent": xml_b64}
    ],
}
zugferd_resp = requests.post(
    "https://api.pdf4me.com/api/v2/AddAttachmentToPdf", json=attach_payload, headers=headers
).json()

# zugferd_resp["docContent"] is now the finished ZUGFeRD PDF/A-3b file, Base64-encoded

One honest flag: PDF4me's own Create PDF/A docs page renders its response example inconsistently with every other endpoint here, so double check the exact response key your account actually returns before wiring pdfa_resp["docContent"] into production. Every other call in this chain uses consistent docContent/docName naming, and it's a safe bet Create PDF/A does too, but verify against a real response rather than trusting a docs page's formatting on this one.

Going the other direction, Extract Attachment from PDF does the reverse: hand it a ZUGFeRD PDF, get back the embedded XML as structured data, live-verified as an outputDocuments array of {fileName, streamFile} objects, one per embedded file, exactly what a receiving ERP system needs to actually consume the invoice instead of just archiving it unread.

Knowing this matters even if you never touch the REST API directly. It explains what PDF4me's no-code action is doing under the hood, and it tells you where to look if a generated file doesn't validate the way you expect.

Which approach to reach for depends on how much control the job needs. Calling Create PDF/A and Add Attachment to PDF yourself makes sense if you're already generating the invoice PDF through your own template engine and just need the final embedding step, or if you want to validate the XML against your own schema before it goes anywhere near the PDF. Reaching for Create ZUGFeRD Invoice directly makes more sense the moment you're already living inside Make, Zapier, Power Automate, or n8n for the rest of the invoicing flow, since it collapses both REST calls, plus the conformance-level bookkeeping, into a single configured step you're not maintaining yourself.

The one-action version

Chaining two REST calls yourself is a reasonable way to build this, but PDF4me also ships it as a single purpose-built action, Create ZUGFeRD Invoice, across all four automation platforms this cluster covers. Feed it invoice data as XML, JSON, or CSV, pick a conformance level, and get back a hybrid PDF/A-3 file with the XML embedded and aligned to EN 16931. No manual REST chaining required.

In Make, the action accepts invoice data in any of those three formats and returns the ready-to-send hybrid file. A documented four-module Dropbox workflow walks through the whole thing: pull a base PDF and a ZUGFeRD 2.0+ XML file from Dropbox, run them through Create ZUGFeRD Invoice at EN16931 conformance, push the finished hybrid invoice back to Dropbox.

Zapier's version supports ZUGFeRD 1.0 and the full 2.x line, across BASIC, COMFORT, EXTENDED, EN16931, and XRECHNUNG conformance. Its Dropbox + XML walkthrough triggers on a new file landing in Dropbox, fetches the base PDF and XML payload, runs Create ZUGFeRD Invoice with XmlWithPdf output, and saves the result back to Dropbox at BASIC conformance in the documented example.

Power Automate's action is built explicitly around the German B2B mandate, and pulls source data from SharePoint, OneDrive, Outlook, or Dataverse in addition to XML, JSON, or CSV. Two documented walkthroughs cover the two source-format paths you're most likely to hit: a Dropbox + JSON flow for teams generating invoice data programmatically, and a Dropbox + XML flow for teams that already have ZUGFeRD-formatted XML sitting in a system somewhere and just need it embedded.

n8n's action generates ZUGFeRD 2.0 through 2.4, with EN16931, XRECHNUNG, BASIC, and EXTENDED conformance, from XML, JSON, or CSV. Its Dropbox + JSON walkthrough uploads invoice JSON, runs it through the ZUGFeRD action, and lands the finished file back in Dropbox, with real screenshots of every mapping.

What this doesn't do for you

A structurally valid ZUGFeRD file isn't automatically an invoice your counterparty's accounts-payable system will accept without complaint. Conformance levels exist precisely because different trading partners and national profiles expect different amounts of structured detail, and whether your invoice data actually satisfies EN 16931's business rules is a data-quality question the generation step alone doesn't answer for you. PDF4me's Validate PDF/A action can confirm the PDF/A-3 container itself conforms to ISO 19005, a useful gate before anything ships, though it checks the container, not ZUGFeRD's own business-rule validation of the embedded XML. That business-rule check isn't a single fixed target either: EN 16931's rules ship as a Schematron ruleset, and the profiles layered on top, XRechnung and each country's CIUS, pin their own ruleset releases on their own schedules. A file that validates cleanly today can fail after one of those releases updates, with nothing in your own code having changed. Store the ruleset version that validated each invoice alongside the pass/fail result, not just the boolean, so you can still answer "was this invoice valid when we sent it" months later. Build that check into your pipeline before this touches production traffic, not after the first rejected invoice comes back.

Which conformance level to pick isn't really a technical question, it's a contractual one. Ask the receiving business, or their invoicing software vendor, which profile they expect. EN16931 and XRECHNUNG are the two most commonly required for the German mandate specifically, so match what's asked for rather than defaulting to EXTENDED because it sounds more thorough.

Getting started

Every action above sits behind the same PDF4me V2 REST API, so the authentication and base URL story is identical whether you're calling Create PDF/A and Add Attachment to PDF yourself, or letting Create ZUGFeRD Invoice do both in one step through whichever automation platform your team already runs on.

Germany's mandate is the concrete deadline in front of anyone shipping invoices there today. Building the pipeline once, with a tool that already understands PDF/A-3's attachment mechanics, beats re-explaining to a new hire every few months why an invoice PDF has a file attached to it.

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

Text Stamps vs. Watermarks: Same Visual Result, Two Different API Calls

PDF4me — Mon, 03 Aug 2026 03:39:39 +0000

Ask a developer to add a "watermark" to a PDF and they picture gray text on a diagonal, something like CONFIDENTIAL bleeding through the page. Ask for a "stamp" and they picture a logo in the corner. PDF4me's own docs use both words for both things, sometimes on the same page. That's not sloppy naming. It reflects a real split under the hood: two separate REST endpoints for what looks, on screen, like one feature.

Send an image file to the endpoint built for text, or a hex color code to the one built for images, and you'll get a 500 that has nothing to do with your API key. Here's exactly where the line sits between the two, verified against the live docs and the official sample repo, plus what happens to the naming once you leave raw REST for Power Automate, Make, Zapier, or n8n.

Authentication, once, for both endpoints

Every PDF4me REST call needs a Base64-encoded API key in the Authorization header. Full details, including how to get a key and encode it, live in Connect to the PDF4me V2 API. Get that working once and both endpoints below are ready.

Add Text Stamp to PDF: `POST /api/v2/Stamp`

Add Text Stamp to PDF renders a string onto a page and gives you granular control over how it looks. Required fields: docName, docContent (Base64 source PDF), pages, text, alignX, alignY. The optional fields are where the control lives: fontName (Arial, Times New Roman, Helvetica, Courier New), fontSize (8-72), fontColor as hex, isBold/isItalics/underline, rotate (0, 45, 90, or -45), opacity (0-100), isBackground to push it behind existing content, showOnlyInPrint, and fitTextOverPage to auto-scale the text to the page.

Verified live against the official Python sample (MIT licensed), the core request looks like this:

import base64
import requests

api_key = "get the API key from https://dev.pdf4me.com/dashboard/#/api-keys"
url = "https://api.pdf4me.com/api/v2/Stamp"

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

payload = {
    "docContent": pdf_base64,
    "docName": "output.pdf",
    "pages": "all",
    "text": "CONFIDENTIAL - PDF4me Watermark",
    "alignX": "center",          # lowercase: left, center, right
    "alignY": "middle",          # lowercase: top, middle, bottom
    "opacity": "30",
    "fontName": "Arial",
    "fontSize": 24,
    "fontColor": "#FF0000",
    "isBold": True,
    "rotate": 45,
    "isBackground": True,
    "async": True
}

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

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

A 200 returns docName and docContent (the stamped PDF, Base64) directly. A 202 means async processing kicked in: pull the Location header and poll it until you get a 200 with the same JSON shape. That polling loop is fully worked out in the sample repo linked above, worth reading before you write your own.

Add Image Stamp to PDF: `POST /api/v2/ImageStamp`

Add Image Stamp to PDF is a different endpoint entirely, and the required fields make that obvious immediately: docName, docContent, imageName, imageFile (your logo, also Base64), alignX, alignY. No text field. No fontColor. In their place: heightInMM/widthInMM (10-200mm) or heightInPx/widthInPx (20-600px) for sizing, and support for JPG, PNG, GIF, and other standard formats.

import base64
import requests

api_key = "get the API key from https://dev.pdf4me.com/dashboard/#/api-keys"
url = "https://api.pdf4me.com/api/v2/ImageStamp"

with open("sample.pdf", "rb") as f:
    pdf_base64 = base64.b64encode(f.read()).decode("utf-8")
with open("logo.png", "rb") as f:
    image_base64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": pdf_base64,
    "docName": "output.pdf",
    "imageFile": image_base64,
    "imageName": "logo.png",
    "alignX": "Center",          # capitalized here: Left, Center, Right
    "alignY": "Middle",          # capitalized here: Top, Middle, Bottom
    "heightInMM": "30",
    "widthInMM": "30",
    "opacity": 50,
    "isBackground": True,
    "async": True
}

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

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

Notice the alignX/alignY values flip capitalization between the two endpoints, lowercase on Stamp, capitalized on ImageStamp. That inconsistency is real and confirmed directly against both live docs pages, not a typo in this article. It's the kind of thing that passes code review and fails at runtime.

The other tell: there's no rotate parameter anywhere on the image endpoint. Need a rotated logo? Rotate the source image before you send it. This API call won't do it for you.

Picking the right one

The rule: a string of characters goes through /api/v2/Stamp. A graphic, logo, scanned signature, seal, goes through /api/v2/ImageStamp. Plenty of real documents need both in sequence, a signed contract might carry an image stamp of a signature in one corner and a text stamp reading EXECUTED diagonally across the page. Chain the calls: the docContent one endpoint returns is valid input to the next.

Neither endpoint is an "upgrade" of the other. fitTextOverPage will never produce a logo no matter how you tune it, and ImageStamp has no text field to put a dynamic invoice number in. If your watermark needs to vary per document, that's the text endpoint. If it needs to stay pixel-identical across every file, that's the image endpoint.

The naming shifts again outside raw REST

Cross into PDF4me's no-code integrations and the labels don't hold. Power Automate and n8n keep "Stamp" as separate Text Stamp and Image Stamp actions. Make drops "Stamp" entirely for Text Watermark and Image Watermark. Zapier follows Make's convention with Add Text Watermark to PDF and Add Image Watermark to PDF.

Same Stamp/ImageStamp behavior under all four, different search term depending on where you're building. Search "stamp" in Make and you'll come up empty. Search "watermark" in Power Automate and same problem, reversed.

Confirm the shape before it hits production

Rather than debug a live workflow over a flipped capitalization or a missing field, run either endpoint through the API Tester first: text stamp tester or image stamp tester. See the exact request and response before it touches a document that matters.

Two endpoints, two request shapes, at least four labels for the same idea depending on which product surface you're standing in. Know which word your platform uses, know which field set your content needs, and the rest is filling in a form.

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

Watermarking Images and Auto-Correcting Sideways Photos with One API Call

PDF4me — Thu, 30 Jul 2026 18:42:41 +0000

Somebody on your team is opening an image editor to stamp a logo onto a batch of product photos. Somebody else, a few tabs over, is manually rotating a stack of scanned receipts that came in sideways from a phone camera. Neither person thinks of the other's task as related to their own, but structurally they're the same job: send an image in, get a modified image back, repeat it a thousand times without touching a mouse.

Below are three PDF4me image API endpoints that cover both problems, with working Python samples for each, verified against the live parameter tables and the base URL from the Connect to PDF4me API guide.

Stamping a logo onto a photo

Add Image Watermark overlays one image, typically a logo or brand mark, onto another. This is compositing, not PDF-page watermarking: control over position, opacity, and rotation is built into the request.

import requests
import base64

api_key = "YOUR_API_KEY"
base_url = "https://api.pdf4me.com"
endpoint = "/api/v2/AddImageWatermarkToImage"

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

with open("logo.png", "rb") as f:
    watermark_content = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docName": "product-photo.jpg",
    "docContent": doc_content,
    "WatermarkFileName": "logo.png",
    "WatermarkFileContent": watermark_content,
    "Position": "bottomright",
    "Opacity": 0.6,
    "PositionX": 0,
    "PositionY": 0,
    "Rotation": 0
}

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

response = requests.post(base_url + endpoint, json=payload, headers=headers)

if response.status_code == 200:
    with open("watermarked-photo.jpg", "wb") as f:
        f.write(response.content)
else:
    print(response.status_code, response.text)

Position accepts topright, topleft, bottomright, bottomleft, centralhorizontal, diagonal, centralvertical, or custom (paired with PositionX/PositionY). The watermark asset itself is usually fixed, one logo file reused across a whole batch, so this is a parameterized call, not a design decision.

Same operation, no-code: Make's Add Image Watermark to Image, Zapier's Add Image Watermark To Image, n8n's Add Image Watermark To Image node. The interactive API Tester runs the call against a real image in the browser if you want to see placement before wiring anything.

Stamping text instead of a logo

Not every watermark is a static image. A case number, a capture date, a "confidential" label: these are generated per file, which is exactly what a static overlay image can't do. Add Text Watermark controls font, size, color, and opacity through the request itself.

import requests
import base64

api_key = "YOUR_API_KEY"
base_url = "https://api.pdf4me.com"
endpoint = "/api/v2/AddTextWatermarkToImage"

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

payload = {
    "docName": "delivery-photo.jpg",
    "docContent": doc_content,
    "WatermarkText": "CASE-4471",
    "TextPosition": "bottomleft",
    "TextFontFamily": "Arial",
    "TextFontSize": 24,
    "TextColour": "#ffffff",
    "IsBold": True,
    "IsUnderline": False,
    "IsItalic": False,
    "Opacity": 0.9,
    "RotationAngle": 0,
    "PositionX": 0,
    "PositionY": 0
}

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

response = requests.post(base_url + endpoint, json=payload, headers=headers)

WatermarkText is the one field that makes this dynamic: pull it from a spreadsheet row, a timestamp, or a record in whatever system triggered the call.

No-code equivalents: Make's Add Text Watermark to Image, Zapier's Add Text Watermark To Image, n8n's Add Text Watermark To Image. The API Tester's text-watermark page is the fastest way to see what a given font and opacity setting actually produces.

Why phones hand you sideways photos in the first place

Camera sensors don't physically rotate when you turn the phone. Instead, the device writes an EXIF orientation tag, a number that tells a viewer how to rotate the image before displaying it. Software that reads that tag shows the photo upright. Software that doesn't shows exactly what the sensor captured, and that file stays wrong the moment it leaves an EXIF-aware viewer for a report, an email, or a print vendor's system.

Rotate Image by EXIF Data reads that tag and actually rotates the pixels to match it, so the file is correct everywhere afterward. It only takes two fields.

import requests
import base64

api_key = "YOUR_API_KEY"
base_url = "https://api.pdf4me.com"
endpoint = "/api/v2/RotateImageByExifData"

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

payload = {
    "docName": "driver-photo.jpg",
    "docContent": doc_content
}

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

response = requests.post(base_url + endpoint, json=payload, headers=headers)

if response.status_code == 200:
    with open("driver-photo-upright.jpg", "wb") as f:
        f.write(response.content)

That's a genuinely different job from PDF4me's plain Rotate Image endpoint, which turns an image by a fixed angle you specify yourself. Fixed-angle rotation works when you already know the exact correction a whole batch needs. EXIF-based rotation is for when you don't, and can't, because every incoming photo might carry a different tag depending on how it was captured.

No-code equivalents: Make's Auto-Rotate Images by EXIF Data, n8n's Rotate Image By EXIF Data node. The API Tester confirms what a specific file's tag will actually do before it's wired into anything.

Where the no-code coverage runs out

Worth saying plainly: Power Automate has no published action for image watermarking or EXIF-based rotation as of this writing, so a Power Automate-only pipeline needs to call the REST API directly for these three operations. Zapier's rotate action (Rotate Image) only covers the fixed-angle version, not the EXIF-aware one; n8n offers both separately too. If auto-rotation by orientation tag is the actual requirement and Zapier is the only automation layer available, that step currently needs to live somewhere else in the pipeline. Neither gap is a reason to avoid the API, it's a reason to check platform by platform before assuming a specific no-code action already exists.

What's next once the file is correct

Two related endpoints sit one step away from everything above. Once an orientation tag has done its job, some pipelines strip EXIF data out entirely before a file goes anywhere external, since it can carry GPS coordinates and camera details nobody meant to publish: Remove EXIF Tags from Image does that. And if you need to see what's actually in a file's metadata before deciding what to do with it, Get Image Metadata reads it back as structured data instead of guesswork.

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

Pulling plain text out of a Word document with one call, no Word install required

PDF4me — Wed, 29 Jul 2026 03:56:34 +0000

"Extract the text from this Word document" sounds like a one-line task until the document turns out to have three rounds of tracked changes, a comment thread in the margins, and a footer repeated on every page. A naive extraction pass hands back all of it mixed together, with no way to tell the kept text from the deleted text once both have become "content." PDF4me's Extract Text from Word API is built specifically to give you control over that, not just pull raw text out of a .docx file.

Why plain OOXML parsing is not enough

Two paths usually get tried first. One is installing Microsoft Word or Office on a server and driving it through an interop library, which works until licensing at scale and unstable headless Office instances turn a document-processing job into an ops problem. The other is unzipping the .docx and parsing the OOXML XML directly, which works until a document with tracked changes or embedded comments shows up and the output is full of reviewer names, deletion markup, and boilerplate that never belonged in the final text.

The REST endpoint sidesteps both: send a Base64-encoded .docx, get back clean text, with four content-filtering options doing the real work.

The endpoint

POST https://api.pdf4me.com/api/v2/ExtractTextFromWord

Required parameters:

Parameter	Type	Description
docName	String	Source file name, with or without the .docx/.doc extension
docContent	Base64 (String)	The Word document content, Base64-encoded
StartPageNumber	Integer	First page to extract
EndPageNumber	Integer	Last page to extract
RemoveComments	Boolean	Strip comment text from the output
RemoveHeaderFooter	Boolean	Strip repeated header/footer content
AcceptChanges	Boolean	Accept tracked changes before extracting, rather than rejecting them

Optional:

Parameter	Type	Description
async	Boolean	When true, returns 202 Accepted with a Location header to poll instead of blocking

A synchronous call returns 200 OK with:

{
  "extractedText": "Extracted text content from Word document pages 1 to 3...",
  "fileName": "output.txt"
}

A working Python example

Verified against the official Python sample in pdf4me/pdf4me-api-samples (MIT licensed), field names and endpoint match the live docs page exactly:

import base64
import requests

api_key = "YOUR_API_KEY"  # from https://dev.pdf4me.com/dashboard/#/api-keys/
url = "https://api.pdf4me.com/api/v2/ExtractTextFromWord"

with open("sample.docx", "rb") as f:
    doc_base64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": doc_base64,
    "docName": "sample.docx",
    "StartPageNumber": 1,
    "EndPageNumber": 3,
    "RemoveComments": True,
    "RemoveHeaderFooter": True,
    "AcceptChanges": True,
    "async": False
}

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

response = requests.post(url, json=payload, headers=headers, timeout=300)

if response.status_code == 200:
    result = response.json()
    print(result["extractedText"])
else:
    print(f"Error {response.status_code}: {response.text}")

For large documents, set "async": True instead. The API returns 202 Accepted with a Location header, and polling that URL with the same Authorization header until it returns 200 gets the same extractedText payload once processing finishes. The official sample script handles both paths, sync and the polling loop, in one file, worth a look before writing your own retry logic.

The same options, in a no-code flow

The four content-filtering options are not REST-only. The n8n node exposes the same page range, comment, header/footer, and tracked-changes controls, and accepts input as binary data, Base64, or a URL, whichever fits the flow already moving the file around. The Zapier action, the Make module, and the Power Automate action all describe the identical underlying behavior, just as configuration fields inside their own flow builders. A team automating this inside Power Automate as part of a Microsoft 365 approval flow is calling the same extraction logic a backend service hits directly over REST. There is one engine under all five surfaces, not five different implementations to keep in sync.

Test it before wiring it up

Comment and tracked-change handling is configurable, not automatic, and every document set carries its own editing history. Before committing to a set of flags in code, PDF4me's interactive API Tester lets you upload a real .docx, toggle the page range and filtering options, and see the extracted text come back in the browser first. It catches a mismatched assumption about a document set before that assumption is baked into a pipeline.

Getting a key and the request contract

New to the API: the Getting Started guide covers account creation, generating a key from the developer dashboard, and making a first authenticated call. Every endpoint, this one included, follows the same V2 REST API contract: POST with a JSON body, the file as Base64 in docContent or a public URL in docUrl, docName carrying the extension that tells PDF4me which engine to route to, and a Base64-encoded API key sent as a Basic auth header.

What it will not do

This endpoint returns plain text, not structure. Tables come back as text, not as tables, and heading-versus-body distinctions are not preserved, so anything downstream that needs document structure intact needs a different step, not this one. And because comment and tracked-change handling is a choice rather than a default, it is worth deciding upfront, per document type, whether "final text only" or "everything including edit history" is the actual goal, since those are two different configurations of the same call, not two outputs from one default request.

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

Branding and Cleaning Up Spreadsheets Without Opening Excel

PDF4me — Mon, 27 Jul 2026 14:15:30 +0000

Someone on your finance team exports a report every Friday. Before it goes out: a "DRAFT" watermark goes across every sheet, the company logo lands in the header, and the internal notes tab gets deleted before anyone outside the building sees it. Right now a human does this by hand in Excel, every week, and every so often forgets the third step.

None of that requires Excel to be open. It requires a few API calls.

PDF4me treats an Excel workbook as something a server can edit directly: watermark it, stamp a header or footer onto it, add or remove a worksheet, all without Excel installed anywhere in the pipeline. That matters more than it sounds like it should. Most teams don't have a spare Excel license sitting on a server, and the alternative (a VBA macro that only runs on someone's desktop, by hand, when they remember) is exactly the manual step automation is supposed to remove.

Watermarking a workbook the same way you'd watermark a PDF

Add Text Watermark does for Excel what a text stamp does for a PDF: font, transparency, and positioning are parameters you set once and reuse. "CONFIDENTIAL" across an HR export, "DRAFT" across a report still in review, an internal classification label before a workbook lands in the wrong inbox: it's the same call with a different string.

The endpoint is a straight POST, confirmed against the live docs:

POST https://api.pdf4me.com/api/v2/office/ApiV2Excel/ExcelAddWatermark
Content-Type: application/json
Authorization: Basic YOUR_BASE64_ENCODED_API_KEY

import base64
import requests

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

payload = {
    "document": {"Name": "data.xlsx"},
    "docContent": doc_content,
    "addWatermarkToExcelAction": {
        "watermarkText": "CONFIDENTIAL",
        "fontFamily": "Arial",
        "fontSize": 48,
        "fontColor": "#808080",
        "semiTransparent": True
    }
}

response = requests.post(
    "https://api.pdf4me.com/api/v2/office/ApiV2Excel/ExcelAddWatermark",
    json=payload,
    headers={"Authorization": "Basic YOUR_BASE64_ENCODED_API_KEY"}
)
result = response.json()

watermarkText is the only required field inside addWatermarkToExcelAction. Everything else (fontFamily, fontSize, fontColor, semiTransparent, cultureName) has a documented default, so a minimal call is genuinely minimal.

Remove Watermark does the reverse, and worksheet targeting means you can strip a watermark from one tab of a multi-sheet workbook without touching the rest, which matters once a workbook has more than one sheet in it.

If you're automating this without writing your own integration code, the same operation exists as a native step in Make, Zapier, Power Automate, and n8n, with removal available the same four ways: Make, Zapier, Power Automate, n8n.

A header and footer is a page setup change, and it's still one API call

Worth being precise here: a watermark sits visually behind or across the cell content. A header or footer lives in Excel's page setup, the same strip of space that would show a printed page number if you set it manually by hand. They're different mechanisms solving overlapping problems, which is why branding a workbook often needs both at once.

Add Text Header/Footer covers font styling, color, and orientation for text content: page numbers, a "Confidential, internal use only" line that prints on every page rather than sitting over the data. Add Image Header/Footer does the same for a logo file, with positioning, worksheet selection, and margins, so a company logo lands in the same spot on every sheet without anyone dragging an image box around in Excel. Remove Header/Footer clears either kind, again with worksheet targeting.

Same four-platform pattern as watermarking. Text headers and footers: Make, Zapier, Power Automate, n8n. Image headers and footers: Make, Zapier, Power Automate, n8n. Removal: Make, Zapier, Power Automate, n8n.

The tab nobody meant to send

The most common spreadsheet accident isn't a formatting problem, it's a worksheet problem. A workbook built for internal use has a tab called "Notes" or "Raw Data" or someone's name, and it goes out the door attached to an external email because nobody remembers to delete it before hitting send.

Delete Worksheets removes a sheet by name or index as a normal pipeline step, which means the step that used to depend on a human's memory now depends on nothing at all.

import base64
import requests

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

payload = {
    "document": {"Name": "monthly-report.xlsx"},
    "docContent": doc_content,
    "deleteWorksheetToExcelAction": {
        "worksheetNames": ["Internal Notes"]
    }
}

response = requests.post(
    "https://api.pdf4me.com/api/v2/office/ApiV2Excel/ExcelDeleteWorksheet",
    json=payload,
    headers={"Authorization": "Basic YOUR_BASE64_ENCODED_API_KEY"}
)
result = response.json()

You can target by worksheetNames (an array, so multiple tabs in one call) or worksheetIndexes if the sheet order is more stable than its name in your source system.

Extract Worksheets does the inverse job: pull specific sheets out of a multi-sheet file into their own workbook, by name or index, which is what a "send only the client-facing tab" workflow actually needs under the hood. Chain that per sheet and you get worksheet separation, splitting one workbook into one file per tab, documented as its own integration step in Make, Zapier, and Power Automate.

Delete and extract are available across the same four platforms too. Delete: Make, Zapier, Power Automate, n8n. Extract: Make, Zapier, Power Automate, n8n.

Why this belongs in a workflow, not a script someone has to remember to run

A script that runs when a human remembers to run it isn't automation. It's a manual step with extra keystrokes. These operations belong as steps in Make, Zapier, Power Automate, or n8n rather than a standalone script because they attach to a trigger: a file lands in a folder, a form gets submitted, a scheduled time arrives, and the watermarking, branding, and cleanup just happen.

If you're building your own application instead of wiring together no-code steps, every endpoint above sits behind the same PDF4me V2 REST API, authenticated the same way, so nothing here is locked to any one platform. Base URL is https://api.pdf4me.com, every request is a POST, and the response comes back as a base64-encoded document in JSON alongside a success flag and fileName. That consistency across every Excel endpoint (watermark, header/footer, worksheet) is what makes chaining several of these calls into one pipeline straightforward instead of a new integration each time.

One honest limit worth stating plainly: this isn't a formula engine, and it isn't a substitute for Excel's own calculation layer. It edits structure, presentation, and branding: watermarks, headers, footers, and which worksheets exist in a file. If the job is recalculating formulas or manipulating cell data at scale, that's a different set of operations (row-level add, update, delete, and merge), worth its own read if that's the problem you're actually solving.

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

Excel as a Database: Updating, Deleting, and Merging Rows Over One API

PDF4me — Thu, 23 Jul 2026 14:29:00 +0000

Most teams don't think of Excel as a database. It's the thing you open before a meeting, not something you'd call from production code. But look at how a lot of internal tools actually work: a workbook sits in a shared drive, a script or a no-code flow reads it, changes a few rows, and writes it back. Nobody built that on purpose. It accumulated, one manual edit at a time, until the spreadsheet became the source of truth nobody wants to admit is the source of truth.

The problem isn't that Excel is a bad database. It's that the operations you'd actually want (updating a row when a status changes, deleting rows that failed validation, merging duplicate entries after two systems both wrote to the same sheet) still get done by hand in most shops. Someone opens the file, finds the row, edits it, saves it, and hopes nobody else had it open at the same time.

PDF4me's Excel API turns three of the most common versions of that work, update, delete, merge, into calls you can drop into a pipeline. No macro, no VBA, no "don't touch that cell" tribal knowledge. Here's what each one actually does, the request shape behind it, and where it fits.

Authenticating your requests

Every call below hits the same base URL, https://api.pdf4me.com, under the /api/v2/ path, authenticated with an API key from your PDF4me dashboard. Full setup is in the Connect to PDF4me API guide; the short version is a Basic auth header carrying your Base64-encoded key.

Updating rows without opening the file

The Update Rows endpoint (POST office/ApiV2Excel/ExcelUpdateRows) takes an existing Excel file and a set of new values, and writes those values into specific rows, targeted either by table structure or by direct coordinates. Coordinate-based targeting is what you want when you know exactly which cell you're touching, row 14, column C. Table-based targeting is what you want when the sheet has headers and you'd rather match by field name than by position, which matters the moment someone inserts a column and every hardcoded coordinate in your script quietly points at the wrong data.

import base64
import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.pdf4me.com/api/v2/"

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

payload = {
    "document": {"Name": "data.xlsx"},
    "docContent": doc_content,
    "updateRowsToExcelAction": {
        "jsonInput": '[{"Name": "John", "Age": 31}]',
        "worksheetName": "Sheet1",
        "tableName": "SalesTable",
        "excelRowNumber": 5,
        "convertNumericAndDate": True,
        "cultureName": "en-US"
    }
}

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

response = requests.post(BASE_URL + "office/ApiV2Excel/ExcelUpdateRows", json=payload, headers=headers)
result = response.json()

tableName switches the call into table-based mode; leave it empty and use insertFromRow / insertFromColumn instead for coordinate-based mode. The response comes back as a Base64-encoded document alongside fileName, success, and errorMessage fields, the same shape across all three endpoints below.

The automation-platform versions add the parts a developer would otherwise have to build by hand. In Make, the module does automatic header matching, type conversion, and culture-specific formatting, so a JSON payload from another app lands in the right cell as the right data type instead of as a string that happens to look like a number. Power Automate does the same header matching and type conversion, aimed at flows where a form submission or a database row needs to land back in a shared workbook with nobody touching it manually. Zapier's action modifies existing spreadsheet rows in place from JSON, exactly the shape you'd reach for to keep CRM, inventory, or reporting data synced against a spreadsheet without manual editing. And in n8n, the node matches JSON arrays to worksheet headers while giving you control over the starting row and column offsets, and it preserves the workbook's existing formulas while it refreshes the data around them. That last detail decides whether a self-hosted workflow is safe to run against a sheet someone else already built calculations into.

Picture the workflow this actually replaces: a support ticket closes, and someone is supposed to open the shared "Active Accounts" workbook finance still swears by, find the account row, and flip a status column from "Open" to "Resolved." Multiply that by however many tickets close in a day, and the manual version is where status columns quietly go stale. Wiring the ticket-close event straight into an Update Rows call means the workbook reflects reality the moment the ticket does, not whenever someone remembers to open it.

Deleting rows without breaking the ones after them

Deleting rows sounds simpler than updating them, right up until you've done it wrong once. Delete row 5, and every row after it shifts up by one. Delete rows 5 and 8 in that order, and row 8 was never actually row 8 by the time your script got to it.

The Delete Rows endpoint (POST office/ApiV2Excel/ExcelDeleteRows) removes rows by index range, scoped to a specific worksheet:

payload = {
    "document": {"Name": "data.xlsx"},
    "docContent": doc_content,
    "deleteRowsToExcelAction": {
        "worksheetName": "Sheet1",
        "fromRow": 5,
        "toRow": 10
    }
}

response = requests.post(BASE_URL + "office/ApiV2Excel/ExcelDeleteRows", json=payload, headers=headers)

The endpoint, and every automation-platform version, handles the ordering problem the same way: bottom to top. In Zapier, you pass a range syntax like "1-5,10,15-20" and bottom-to-top processing prevents the index-shifting error described above. Make uses the same comma-separated range syntax with safe bottom-to-top deletion, built for cleanup work: pulling failed rows out of a report, trimming a sheet before it goes to a client, or clearing rows that a retention schedule says shouldn't stick around. Power Automate removes single rows, multiple rows, or comma-separated ranges from any worksheet inside a flow. n8n's version removes single rows, ranges, or mixed lists from any worksheet, without shifting the rows you didn't ask it to touch.

Don't write your own row-deletion loop unless you enjoy debugging off-by-one errors in someone else's spreadsheet. A nightly QA job that flags failing rows and needs them out of the working sheet before it goes anywhere else is the textbook case: a single Delete Rows call, driven by whatever range your validation step already produced, removes the guesswork along with the rows.

Merging duplicate rows without a pivot table

The Merge Rows endpoint (POST office/ApiV2Excel/ExcelMergeRows) is really a deduplication tool wearing a merge-rows name. It targets a worksheet or table, groups rows by a key column you choose, and consolidates the values that differ across the group instead of picking one row and discarding the rest:

payload = {
    "document": {"Name": "data.xlsx"},
    "docContent": doc_content,
    "mergeRowsToExcelAction": {
        "jsonInput": '[{"Name": "John", "Age": 30}]',
        "worksheetName": "Sheet1",
        "tableName": "CustomerTable",
        "convertNumericAndDate": True,
        "cultureName": "en-US"
    }
}

response = requests.post(BASE_URL + "office/ApiV2Excel/ExcelMergeRows", json=payload, headers=headers)

That consolidation behavior is where the automation-platform versions get specific. Make's implementation groups on key columns and does value consolidation using a semicolon-separated format, then removes the duplicates, built for comprehensive data deduplication across a sheet two systems have both been writing to. Zapier's action groups on key columns to combine customer orders, product variants, or category data that landed as separate rows when they should have been one. Power Automate groups duplicate rows by a key column and combines the differing values with semicolon separators inside the flow. n8n's node groups by key columns, combines values with the same deduplication logic, and exports the result to multiple formats, useful when the merged sheet needs to go somewhere other than back into Excel.

Merge Rows is the one of the three that most often gets skipped in favor of a manual pivot table and a lot of copy-paste. It's also the one where doing it by hand is most likely to silently drop a value nobody notices missing until a customer asks about it. Two intake forms feeding the same customer list, one row with a phone number and the other with a billing address for the same person, is the scenario this exists for: group on the customer key, let the endpoint consolidate the differing fields, and nobody has to make that judgment call thirty times before lunch.

Picking REST or a no-code platform, and why it's not really a hard choice

None of this requires picking a side. The REST endpoints and the no-code platform actions do the same underlying work, so the choice comes down to where the trigger for the row change actually lives, not which tool is "better." If you're already inside a codebase, the REST API is the direct path: authenticate once and call the endpoint from wherever your pipeline already runs. If the trigger lives somewhere else, a form submission, a webhook, a scheduled check, that's what Power Automate, Make, Zapier, and n8n connections exist for, so a team without a developer on hand for that one workflow still gets the same row-level behavior through a flow they can read and edit themselves.

Here's the honest limit: none of these three run inside a single combined call. Update, delete, and merge are three separate requests, chained in whatever order your workflow needs, not one operation that does all three at once. On the REST side, that's three sequential calls, exactly as simple and exactly as much your own responsibility to sequence correctly as it sounds.

Spreadsheets aren't going away as a business interface. Realistically, they shouldn't. The teams that get the most out of an Excel API like this one aren't the ones who stopped using Excel. They're the ones who stopped treating every row edit as a task for a human.

Full runnable samples in more languages (C#, Java, Node.js) live in the pdf4me-api-samples repo under Excel/Update Rows, Excel/Delete Rows, and Excel/Merge Rows. New to the API: start with Getting Started with API Portal.

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

What Your Code Can Know About a PDF Before It Touches a Single Page!!

PDF4me — Wed, 22 Jul 2026 12:20:44 +0000

There are two PDF4me endpoints that sound like they do the same thing: GetPdfInformation and GetPdfMetadata. Both take a PDF and hand back facts about it before your code opens it, edits it, or moves it anywhere. The overview version of this piece covers when to reach for each one. This is the version with the actual requests: real field names, a full working script, and one behavior that only shows up once you read the sample code instead of the docs page.

Same idea, different keys

Here's the part that trips people up. The two endpoints don't even use the same JSON keys for the same data.

POST https://api.pdf4me.com/api/v2/GetPdfInformation

{
  "File Name": "document.pdf",
  "File Content": "JVBERi0xLjQK..."
}

POST https://api.pdf4me.com/api/v2/GetPdfMetadata

{
  "docContent": "JVBERi0xLjQK...",
  "docName": "output.pdf",
  "async": true
}

Both fields hold the same thing (a filename and the file's Base64 content) but GetPdfInformation takes File Name / File Content, and GetPdfMetadata takes docContent / docName. Copy-pasting a payload from one endpoint to the other silently fails, because the fields it's expecting just aren't there. Worth checking the exact key names for whichever endpoint you're calling instead of assuming they match, even though the docs read like they should.

Both use the same header pattern:

Content-Type: application/json
Authorization: Basic {api_key}

A working script for GetPdfMetadata

This is adapted from PDF4me's own sample repository (MIT licensed), trimmed down to the request/response logic:

import base64
import requests
import time

api_key = "YOUR_API_KEY"
url = "https://api.pdf4me.com/api/v2/GetPdfMetadata"

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

def get_pdf_metadata(file_path):
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Basic {api_key}",
    }
    payload = {
        "docContent": read_and_encode_pdf(file_path),
        "docName": "output.pdf",
        "async": True,
    }

    response = requests.post(url, headers=headers, json=payload, timeout=30)

    if response.status_code == 200:
        # Synchronous: metadata comes back in the response body
        return response.json()

    if response.status_code == 202:
        # Asynchronous: poll the Location header until it's done
        location_url = response.headers.get("Location")
        for attempt in range(10):
            time.sleep(10)
            poll = requests.get(location_url, headers=headers)
            if poll.status_code == 200:
                return poll.json()
            if poll.status_code != 202:
                poll.raise_for_status()
        raise TimeoutError("Metadata extraction did not complete in time")

    response.raise_for_status()

metadata = get_pdf_metadata("sample.pdf")
print(metadata)

Two response codes to handle: 200 returns the metadata JSON directly, 202 means it's processing async and hands you a Location header to poll. The official sample polls up to 10 times, 10 seconds apart, which is a reasonable starting point for anything that isn't a batch job.

GetPdfInformation, same pattern, smaller payload

There's no official Python sample published for this endpoint yet (only a C# one, in the same repo), but it follows the identical auth and encoding pattern, just with its own field names and no documented async option:

import base64
import requests

api_key = "YOUR_API_KEY"
url = "https://api.pdf4me.com/api/v2/GetPdfInformation"

def get_pdf_information(file_path):
    with open(file_path, "rb") as f:
        content = base64.b64encode(f.read()).decode("utf-8")

    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Basic {api_key}",
    }
    payload = {
        "File Name": "document.pdf",
        "File Content": content,
    }

    response = requests.post(url, headers=headers, json=payload, timeout=30)
    response.raise_for_status()
    return response.json()

info = get_pdf_information("sample.pdf")
print(info)

The response here is flatter too: a single Metadata Info field rather than the structured document/file/security breakdown GetPdfMetadata returns. If your triage logic just needs author, title, and encryption status, this is the lighter call.

The async flag the docs page doesn't mention

This is the part worth flagging for anyone who read the marketing docs page and stopped there. docs.pdf4me.com's own request example for GetPdfMetadata shows a two-field payload, no async flag anywhere. But PDF4me's official sample script sends "async": true by default and handles a 202 Accepted response with polling. That behavior exists at the REST level, it's just not visible unless you go read the sample code instead of the parameter table.

Practically: for a single small file, the endpoint can return 200 with the metadata inline. For larger files, or under load, expect a 202 and a Location header to poll. Build for both from the start rather than assuming a hardcoded 200 handler covers production traffic.

That also puts n8n's GetPdfMetadata node in a different light. Its Async toggle isn't just an n8n-side convenience, it's very likely surfacing this exact REST-level async parameter. That's an inference from matching behavior, not something n8n's own docs state outright, so treat it as a reasonable working assumption rather than a confirmed 1:1 mapping.

Where this shows up outside a raw HTTP client

Power Automate is the only platform with both actions as separate, named steps, each taking the same File Name / File Content pair, mappable straight from SharePoint, OneDrive, or an email trigger. Zapier ships a GetPdfMetadata action that takes a File and File Name. n8n's GetPdfMetadata node adds the input-format choice (binary, Base64, or URL) plus the Async toggle covered above.

There's no Make module for either endpoint yet, and no dedicated Zapier or n8n page for GetPdfInformation specifically. If you're on Make, or need GetPdfInformation inside Zapier or n8n today, the REST call above is the way in.

The practical takeaway

Match the endpoint to the question. "Who made this file, and is it locked?" is GetPdfInformation. "Does this meet an archival, size, or signature standard, and how many pages is it?" is GetPdfMetadata. Run the cheaper call where you can, and build the 202/polling path for GetPdfMetadata from day one rather than retrofitting it after the first large file times out in production.

(A more editorial, less code-heavy version of this piece is also up on Medium and Hashnode.)

Learn more

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

DEV Community: PDF4me

Draft vs High: The OCR Quality Parameter Nobody Reads the Docs For

What the quality setting is actually deciding

Five surfaces, two different vocabularies

The other setting worth knowing about: OCR Only When Needed

The language parameter isn't formatted the same way twice either

Calling it directly: a live-verified request

When to reach for the heavier setting even on a file that looks fine

A checklist worth keeping next to your workflow

Blank Pages Are a Data Quality Problem Before They're a Design Problem

Why "just skip it visually" doesn't scale

"Blank" is a choice, not a single definition

Where this belongs in a pipeline, and where it doesn't

Calling it directly

Running it without hand-rolling REST calls

Where this needs judgment, not just a default

Splitting a PDF by the text on the page, not a barcode you don't have

What's actually happening under the hood

Where this actually pays off, and where it doesn't

Testing it before it touches a pipeline

Where it plugs in

The actual test

HTML Headers and Footers: Styling PDF Margins With CSS Instead of a PDF Library

What the endpoint actually takes

In code

Where this stops being a library problem

The one thing this endpoint is not

Testing the HTML before it hits a pipeline

Same endpoint, four ways into a workflow

What this does not replace

Numbering Pages the Way Your Print Vendor Actually Wants Them

What the API actually controls

What a vendor spec turns into, in practice

Async for volume

Where this sits next to header/footer stamping

Testing a format before it hits a pipeline

Same endpoint, four ways into a workflow

What this does not do

A PDF a Human Reads and a Machine Parses at the Same Time: How PDF4me Builds ZUGFeRD E-Invoices

What a ZUGFeRD invoice actually is

The two REST primitives underneath it

The one-action version

What this doesn't do for you

Getting started

Text Stamps vs. Watermarks: Same Visual Result, Two Different API Calls

Authentication, once, for both endpoints

Add Text Stamp to PDF: POST /api/v2/Stamp

Add Image Stamp to PDF: POST /api/v2/ImageStamp

Picking the right one

The naming shifts again outside raw REST

Confirm the shape before it hits production

Watermarking Images and Auto-Correcting Sideways Photos with One API Call

Stamping a logo onto a photo

Stamping text instead of a logo

Why phones hand you sideways photos in the first place

Where the no-code coverage runs out

What's next once the file is correct

Pulling plain text out of a Word document with one call, no Word install required

Why plain OOXML parsing is not enough

The endpoint

A working Python example

The same options, in a no-code flow

Test it before wiring it up

Getting a key and the request contract

What it will not do

Branding and Cleaning Up Spreadsheets Without Opening Excel

Watermarking a workbook the same way you'd watermark a PDF

A header and footer is a page setup change, and it's still one API call

The tab nobody meant to send

Why this belongs in a workflow, not a script someone has to remember to run

Excel as a Database: Updating, Deleting, and Merging Rows Over One API

Authenticating your requests

Updating rows without opening the file

Deleting rows without breaking the ones after them

Merging duplicate rows without a pivot table

Picking REST or a no-code platform, and why it's not really a hard choice

What Your Code Can Know About a PDF Before It Touches a Single Page!!

Same idea, different keys

A working script for GetPdfMetadata

GetPdfInformation, same pattern, smaller payload

Add Text Stamp to PDF: `POST /api/v2/Stamp`

Add Image Stamp to PDF: `POST /api/v2/ImageStamp`