DEV Community: PDF4me

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

PDF4me — Tue, 01 Sep 2026 12:52:49 +0000

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

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

What the endpoint actually does

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

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

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

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

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

import base64
import requests

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

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

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

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

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

Four platforms, two very different capability sets

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

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

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

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

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

Where this actually gets used

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

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

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

Before you build, test it live

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

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

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

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

Merging 20 PDFs Into One File Without Losing Which Page Came From Where

PDF4me — Tue, 01 Sep 2026 10:20:09 +0000

Merging PDFs sounds like the simplest operation in the whole document-automation catalog: take several files, stick them together, get one file back. It is, mechanically. What actually causes production incidents is not the merge itself, it's the ordering. A contract package where the signature exhibit lands before the terms it's attached to, a quarterly report where finance's numbers appear ahead of the cover page that's supposed to introduce them, an onboarding packet where page 14 of one PDF ends up sandwiched into the middle of another. None of these are merge failures. They're order failures, and order is entirely the caller's responsibility, not the API's.

PDF4me's Merge endpoint makes that responsibility explicit in a way a lot of merge tools don't bother to. There is no separate sequencing parameter, no drag-and-drop reordering step, no "sort by filename" fallback. The order you send is the order you get back, full stop.

What the endpoint actually does

The REST call is POST /api/v2/Merge. Two fields are required: docContent and docName. One optional field, async, switches large batches to asynchronous processing.

The detail worth pausing on: docContent here is an array, not a single string. Most PDF4me endpoints take one document per call. Merge is one of the few that takes several at once, and the array's index order becomes the merged document's page order. There's no separate order or sequence field sitting next to it. If your source list isn't already in the order you want, you reorder the array before the request goes out, not after.

The response is also unusual for this API: a 200 comes back as raw binary, the merged PDF itself, not a JSON envelope with a Base64 string inside it. Write the response body straight to a .pdf file. Parsing it as JSON or trying to Base64-decode it corrupts the output, and it's a mistake the docs page's own FAQ calls out directly as a common cause of "why is my merged file broken" support tickets. A 202 response, from setting async true, works the same way as PDF4me's other long-running jobs: poll the Location header on roughly a 10-second interval, per the standard pattern in the connect guide, until a 200 arrives with the finished bytes.

curl -X POST https://api.pdf4me.com/api/v2/Merge \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic YOUR_API_KEY" \
  -d '{
    "docContent": ["JVBERi0x...cover...", "JVBERi0x...report...", "JVBERi0x...appendix..."],
    "docName": "quarterly-pack.pdf",
    "async": true
  }' \
  --output merged.pdf

That array order, cover, report, appendix, is the exact page order of the output. Swap two entries and the merged PDF changes with them. Nothing else in the request influences page order at all.

The part that will actually bite you: four platforms, four different shapes for the same list

Here's the finding worth building a workflow decision around, not just a syntax note. The REST engine underneath is identical everywhere. But PDF4me's own integration docs describe four structurally different ways of handing it an ordered list of files, and porting a merge step between platforms means re-learning the shape, not just the field names.

Make's Merge Multiple PDFs module takes a Files array, an Output File Name, and a third parameter none of the other three platforms document at all: Skip Protected PDF's, a boolean that lets a scenario silently skip password-protected input files instead of failing the whole batch. If your source folder sometimes contains a locked PDF, this option only exists on Make. Rebuilding the same scenario in Zapier or n8n means handling protected files yourself, upstream, because the option isn't there to flip.

Zapier's Merge Multiple PDFs action doesn't expose an array field at all in the way Make does. Its Files parameter is a list you build one entry at a time directly in the Zapier UI, mapped from a trigger or a previous step. The docs are explicit that there's no separate sort field: "arrange your trigger data or add file entries in the order you want them to appear in the merged output." Zapier's page also states plainly that PDF4me does not publish a fixed file-count ceiling for this action, so a real 20-file batch is a "test it with your actual batch size" exercise, not a documented hard limit either way.

Power Automate's action is the most structurally different of the four. Its own parameter table doesn't describe an array or a list at all. It lists fixed, numbered slots: File Contents - 1, File Contents - 2, each individually marked required, extended by clicking an Add new item button in the flow designer to get File Contents - 3, File Contents - 4, and so on. Functionally it behaves like a list once you've clicked "Add new item" enough times, but the documented shape of the parameter is numbered discrete inputs, not a single collection value the way Make and Zapier frame it.

n8n's node goes a different direction again. Its PDF Files parameter is a true array, closer to Make's framing, but it adds something none of the other three platforms document: a per-request Input Type selector, letting you choose Binary Data, Base64 String, or a public File URL as the source format for the files being merged. n8n's output is also the richest of the four: alongside the merged file, it returns fileSize, success, and inputFileCount, letting a workflow verify that the number of files it sent actually matches the number PDF4me merged, a check Make, Zapier, and Power Automate's documented outputs don't give you directly.

The one constant across all four genuinely different shapes: input order is output order, everywhere. That's the detail this article's headline is really about. Whatever the platform, however the list is built, whatever you call the parameter, the sequence you hand PDF4me is the sequence the pages come back in. Get the list order right once, and the rest of each platform's quirks (the protected-file skip on Make, the numbered slots on Power Automate, the input-type selector on n8n) are configuration details, not ordering risks.

Where this actually gets used

Contract and closing packages. Main agreement first, exhibits and schedules after, in the exact sequence a signing party or a closing attorney expects. Zapier's own workflow examples walk through exactly this: application form first, then supporting documents, assembled the moment every piece is confirmed present.

Multi-department report consolidation. Power Automate's documented workflow merges a scheduled batch of sales, finance, operations, and HR reports into one quarterly file, with a cover page inserted first so the merged document reads top to bottom the way a reviewer expects, not in whatever order the individual reports happened to be retrieved.

Folder-driven batch merges. A Make blog walkthrough covers the pattern directly: watch a cloud storage folder, iterate over whatever's in it, aggregate the results into an array, then merge, useful precisely because folder listings don't arrive pre-sorted the way a hand-built file list does.

Splitting is the deliberate inverse, not a variant. If the actual need is breaking one document into parts rather than combining several into one, that's Split PDF, a separate endpoint built for the opposite direction. And if the goal is stamping one PDF's pages on top of another's, rather than appending files end to end, that's Merge Overlay, a different operation from plain concatenation despite the similar name.

Before wiring any of this into a production flow, the API Tester's live Merge Multiple PDF Files page lets you send a real request and inspect a real response with no code, worth a five-minute pass before you write parsing logic against an assumption.

The one-line summary

Merge doesn't reorder anything, it can't, it only concatenates in whatever order it's handed. That responsibility sits entirely with the caller, and PDF4me's own four integration surfaces disagree, sometimes sharply, on what shape that ordered list should take when you build it. Learn the shape for the platform you're actually using (Make's protected-file skip, Zapier's no-sort-field list, Power Automate's numbered slots, n8n's input-type selector) rather than assuming it carries over, and the one thing that never changes, page order following input order, stops being a risk and starts being the one guarantee you can build around.

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

A Margin Is a Page Property, Not Decoration: Adding Print-Safe Margins by API

PDF4me — Mon, 31 Aug 2026 12:51:49 +0000

Open a PDF in any desktop editor and "add a margin" feels like a formatting toggle, something you'd expect to sit next to font size or line spacing. It isn't. On PDF4me's Add Margin to PDF endpoint, a margin is a page property. Call it, and the page itself gets physically bigger. A US Letter page (216 x 279mm) with 25mm added on all four sides comes back as 266 x 329mm. Nothing inside moves, shrinks, or reflows. The content sits exactly where it always sat; the page around it just grew.

That distinction matters more than it sounds like it should, because it's the opposite of what a lot of developers reach for first. If you've ever used Crop PDF to trim scanner edges or strip excess white space, Add Margin does the reverse operation on the same page geometry: Crop removes area, Add Margin adds it. Confuse the two and you'll spend an afternoon debugging why your "cropped" PDF got larger instead of smaller.

What the endpoint actually does

The REST call is POST /api/v2/AddMargin. Two fields are required: docName (the output filename) and docContent (the source PDF, Base64-encoded). Four more are optional: marginLeft, marginRight, marginTop, and marginBottom, each an integer from 0 to 100, in millimeters. Leave one out and, per the REST page itself, that side gets no margin added at all, not a zero, just untouched.

The response is JSON, not a raw PDF stream: a docName string and a docContent field holding the new, larger PDF as a Base64 string. Decode that and you have your margin-expanded file. There's also an optional async flag for polling long-running jobs instead of waiting on a synchronous response, useful if you're batching large documents through the connect guide's standard 202-plus-Location-header pattern.

Here's the live Python sample, pulled straight from the official sample repository:

payload = {
    "docContent": pdf_base64,   # Base64 encoded PDF document content
    "docName": "output.pdf",    # Output PDF file name
    "marginLeft": 20,           # Left margin in millimeters (0-100)
    "marginRight": 20,          # Right margin in millimeters (0-100)
    "marginTop": 25,            # Top margin in millimeters (0-100)
    "marginBottom": 25,         # Bottom margin in millimeters (0-100)
    "isAsync": True             # Enable asynchronous processing
}

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

Notice the last field name: isAsync, not async. The REST docs page itself labels this field async in its parameter table. The live, working sample in the repository uses isAsync. This is the same naming mismatch that's shown up on a few other PDF4me endpoints recently, worth double-checking against the API Tester before you write parsing or request-building code that assumes the docs table is field-accurate.

The part that will actually bite you: required versus optional isn't consistent

Here's the more interesting finding, and the reason this is worth an article instead of a changelog line. The REST endpoint treats all four margin fields as optional. Skip a field, that side simply doesn't move. Zapier's action matches that behavior exactly: all four fields are optional, and an omitted side defaults to a zero-millimeter margin, no change.

Make and n8n do not work that way. Both platforms mark all four margin fields as required in their own parameter tables. You don't get to omit a side; you have to explicitly pass 0 for any edge you don't want to expand. Same underlying AddMargin engine on PDF4me's backend, two different contracts depending on which surface is calling it. If you're porting a Zapier zap to a Make scenario (or vice versa) and you were relying on "just don't set the fields I don't need," that flow will break the moment it hits Make or n8n's required-field validation.

Power Automate's page adds a third wrinkle, and it's internally inconsistent on its own terms: only Left Margin is marked required with asterisks in the parameter table, while the description text underneath Top, Bottom, and Right Margin each says "Default is 0 if not specified," which reads as optional. The table's asterisk placement and the prose don't fully agree with each other. If you're building a flow against this connector, test what happens when you actually leave Top, Bottom, or Right blank rather than trusting either the table or the paragraph alone.

The practical takeaway: don't assume behavior carries over when you move an Add Margin call between PDF4me surfaces. Explicitly pass all four values, every time, regardless of which platform you're on. It costs nothing and it's the one pattern that works everywhere without relying on a default that may or may not exist on the surface you're calling from.

Where this actually gets used

The four independent margin values map to real print and compliance requirements, not abstract formatting:

Binding preparation. A left margin of 30 to 40mm (versus 20 to 25mm on the other three sides) leaves room for spiral binding, comb binding, or three-ring holes without eating into the printed content. Power Automate's own workflow examples describe exactly this: insert a 25mm left margin for binding holes as one step in an automated print-preparation flow.

Academic formatting. APA 7th edition, MLA 9th edition, and Chicago Manual of Style all specify exactly 1 inch, which is 25.4mm, not a rounded 25. Zapier's documentation calls this out directly and lists it as one of several standard presets alongside court-filing margins (a larger top margin for clerk stamps and case numbers) and mirrored book-layout margins for facing pages.

Header and footer clearance. Add a top or bottom margin first, then place content in the new white space with Add HTML Header Footer to PDF or Add Page Number to PDF. n8n's own tips explicitly recommend this order: create the clearance first, then stamp into it, rather than crowding existing content.

Standardizing inconsistent incoming documents. If a webhook or shared folder receives PDFs from external suppliers with no consistent layout, running every file through the same four margin values before archiving gives you a uniform page presentation without touching a single page of content.

One more note on precision: all four documented fields are integers on the REST, Power Automate, Make, and n8n surfaces. Zapier's own page is the only one that explicitly shows a decimal example (25.4 for exact 1-inch academic margins) in its documentation, worth confirming directly in the API Tester before you build a workflow that depends on sub-millimeter precision.

The one-line summary

AddMargin doesn't decorate a page, it resizes one, additively and without touching existing content. That's a genuinely useful, narrowly-scoped operation once you know it's doing that instead of the CSS-padding-style overlay the name might suggest. The behavior itself is consistent and predictable across every PDF4me surface. What isn't consistent is whether the four margin parameters are optional or required, and that's the detail worth checking before you ship, not after a batch job halfway through a workflow migration starts throwing validation errors nobody expected.

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

Sign PDF Is Not a Digital Signature: What PDF4me's Signing Endpoints Actually Do

PDF4me — Fri, 28 Aug 2026 18:04:36 +0000

Search PDF4me's docs for "digital signature" and you land on a page whose browser tab title reads "Sign PDF - Digital Signature API." Read past the headline and the page tells you the opposite: "This is a visual signature, not a cryptographic digital signature." That is not a typo. It is two different features sharing a search result, and if you build a contract pipeline assuming the REST endpoint gives you legal non-repudiation, you find out the hard way that it does not.

This is worth untangling before you write any integration code, because the fix is simple once you know which tool does which job. It just is not the tool the page title points you toward first.

What POST /api/v2/SignPdf actually does

The REST Sign PDF endpoint takes a PDF and a signature image, then composites the image onto the page you specify. Required fields: docContent (Base64 PDF), docName, imageFile (Base64 signature image), imageName, alignX (Left, Center, Right), alignY (Top, Middle, Bottom). Optional fields cover sizing (widthInMM/heightInMM or the pixel equivalents), margins, opacity, pages, showOnlyInPrint, isBackground, and async processing.

Here is the official Python sample, trimmed to the request itself and verified against the live sample repository:

import base64
import requests

url = "https://api.pdf4me.com/api/v2/SignPdf"

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

payload = {
    "docContent": pdf_base64,
    "docName": "signed-output.pdf",
    "imageFile": signature_base64,
    "imageName": "signature.png",
    "alignX": "Right",
    "alignY": "Bottom",
    "widthInMM": "50",
    "heightInMM": "25",
    "marginXInMM": "20",
    "marginYInMM": "20",
    "opacity": "100",
    "isBackground": False,
    "isAsync": True
}

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

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

One field name is worth flagging: the REST docs page's own optional-parameters table lists the async flag as async. The official sample script in the repository above sends isAsync instead, and that is the field that actually works against the live API. If you copy the parameter name straight from the docs table, use isAsync, not async.

Call this directly from your own backend in any language, no Acrobat, no browser, no human clicking a signature pad. That part is genuinely true to the pitch. What comes back is a PDF with an image glued to it at the position you specified. There is no certificate, no private key, no cryptographic hash tying the mark to the exact bytes of the document at signing time. Edit the PDF afterward and nothing in the file structure flags that the "signature" now sits on a modified document.

That is a completely legitimate feature to want for internal approval stamps or a cosmetic "reviewed" mark. The problem is only that PDF4me's own page calls it a "Digital Signature API," and that phrase means something specific and different to anyone who has dealt with e-signature compliance before.

What actual cryptographic signing looks like

A cryptographic digital signature binds a private key to the exact contents of a document at signing time, in a way a third party can independently verify and that breaks visibly if the document changes afterward. That is what eIDAS and the ESIGN Act are built around when they talk about tamper-evidence and non-repudiation. PDF4me has this capability, documented consistently across three separate integration pages as certificate-based, X.509 signing with a .pfx or .p12 certificate file and a password protecting its private key.

The parameters look different because the job is different: a Certificate File, a Certificate Password, which page to sign, plus signer metadata (Signer Name, Sign Reason, Sign Location) embedded in the signature itself, and a Visible toggle so the signature can stay cryptographically present while showing no visual mark at all. Digital Sign in Power Automate, Digital Sign PDF in Make, and Digital Sign PDF in Zapier all describe this the same way, down to the same certificate-plus-password input model.

Here is the part that matters if you were planning to call this from your own code the way "not Acrobat" implies: none of the three platforms above expose Digital Sign as a plain REST endpoint. There is no /api/v2/DigitalSignPdf in the API reference; a direct fetch of the URL pattern that would match it returns nothing, and the REST API's own Edit-category sidebar navigation, read directly off the live docs site, lists every signing-adjacent endpoint that exists and Digital Sign is not among them. n8n does not have a Digital Sign action documented at all, only the same visual Sign PDF.

If a no-code connector platform is already part of your stack, this is a non-issue. If your architecture is backend-only by design, the honest options are routing the signing step through Make, Power Automate, or Zapier as one discrete piece of an otherwise custom pipeline, or handling certificate-based signing with your own library and using PDF4me's REST API for everything upstream and downstream of that one step.

Picking the right one before you write any code

The decision comes down to one question: whether this signature needs to survive a legal challenge. If someone could dispute the document was signed, or dispute it was not altered afterward, you need certificate-based signing, not an image overlay. That rules out the REST Sign PDF endpoint regardless of how convenient it is to call directly.

If the signature is cosmetic, an internal sign-off mark, a visual cue in a workflow where the real approval already happened somewhere else, the REST Sign PDF endpoint is the right, lightweight tool, and it genuinely works the way the pitch implies: called from your own backend, no desktop software, no manual step.

Worth testing the visual endpoint interactively before writing integration code, through the Sign PDF API Tester, which, worth noting, is titled "Sign PDF Digitally" on its own page, the same naming pattern repeating a third time. Upload a sample PDF and a signature image, adjust alignment and sizing, and see the actual output before committing to code.

Sign PDF is also documented per platform if you are automating elsewhere in your stack: Sign PDF in Make, Sign PDF in Power Automate, Sign PDF in Zapier, and Sign PDF in n8n all wrap the same visual-signature endpoint described above. If this is your first REST call against PDF4me, start with the connect to the API guide.

The lesson underneath this is not really about signatures. Read the parameter table, not the page title, before building a compliance-sensitive step around a feature name. PDF4me's own documentation makes the distinction clearly once you are two paragraphs into the actual page. The title just does not warn you that you will need to.

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

Flattening a PDF Form Is Not the Same as Protecting It

PDF4me — Fri, 28 Aug 2026 13:14:20 +0000

A finance team collects a signed intake form, flattens it so the fields stop looking like an editable form, and emails it out as the "final" version. Six months later someone asks why the flattened copy opened without a password, printed without restriction, and could still be pulled apart in any PDF editor that touches raw content streams. Nothing was ever protected. The team confused two operations that PDF4me ships as two entirely separate endpoints for a reason.

Flattening and protecting solve different problems. One changes what a document looks like. The other changes who can open it and what they're allowed to do once it's open. Treating the first as a substitute for the second shows up constantly in automated document pipelines built on Power Automate, Make, Zapier, and n8n, where "flatten" is often the last node before a file gets shipped.

What Flatten PDF actually does

The Flatten PDF REST endpoint (POST /api/v2/FlattenPdf) merges AcroForm fields, XFA form data, annotations, signatures, and comments into the static page content. A filled text field stops being a field and becomes plain rendered text. A checkbox becomes a small rendered mark instead of an interactive control. The output has no form left to interact with, so nothing can be refilled or resubmitted through a form-aware viewer.

The request body only needs two fields, per the endpoint's own parameter table: File Content (Base64) and File Name. Worth flagging honestly: the table names them File Content and File Name, but the request-example payload on the same docs page, and the official Python sample below, both use docContent and docName as the actual JSON keys, a naming mismatch this docs site carries on more than one endpoint. Match the payload example, not the table header.

import requests, base64

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

payload = {
    "docContent": pdf_base64,
    "docName": "Flatten_output.pdf",
    "isAsync": True
}
headers = {"Authorization": f"Basic {api_key}", "Content-Type": "application/json"}

response = requests.post("https://api.pdf4me.com/api/v2/FlattenPdf", json=payload, headers=headers)
# 200 -> binary PDF in response.content
# 202 -> poll the Location header URL until it returns 200

Note the field name is isAsync (lowercase i) in the real sample code, not IsAsync. That's the entire feature: no password field, no permission flag, no encryption step. Flatten PDF was never designed to restrict access, and its own documentation doesn't claim otherwise.

Where the confusion starts

The mix-up usually isn't accidental. It's inherited from a nearby field that does double duty. The Fill a PDF Form endpoint has its own KeepPdfEditable parameter, optional, defaulting to false. Leave it at the default and the filled PDF comes back with its form fields already flattened into static text, "useful for delivering a locked record of what was submitted," in the docs' own words. Set it to true and the recipient can reopen the same fields in any PDF viewer and change the values.

That single boolean does exactly what Flatten PDF does on its own, bundled as a convenience step at the end of a fill operation. It's easy to read "flattens the form into static text" and file that mentally under "now it's secure." It isn't. A flattened PDF with KeepPdfEditable: false is just as printable, copyable, and re-editable at the byte level (new text boxes, redaction bypass, image extraction) as any other unprotected file. It only stops the specific action of refilling the original form fields through form tools.

What actually restricts access

That job belongs to Protect Document (POST /api/v2/Protect). It takes a password and a pdfPermission value and returns a new AES-encrypted PDF. The two fields protect against different things: the password gates opening the file at all, while pdfPermission gates what a user can do once they're past the password. pdfPermission is allow-list, not deny-list, so setting it to None blocks printing, copying, editing, annotating, and form filling in one move, and setting it to Fill Forms opens exactly one door while every other action stays shut.

import requests, base64

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

payload = {
    "docName": "output.pdf",
    "docContent": pdf_base64,
    "password": "Str0ng-P@ss!",    "pdfPermission": "Fill Forms",
    "isAsync": True
}
headers = {"Authorization": f"Basic {api_key}", "Content-Type": "application/json"}

response = requests.post("https://api.pdf4me.com/api/v2/Protect", json=payload, headers=headers)

The docs' own parameter table calls this field async, but the official sample code sends isAsync, the same lowercase-i naming this docs site uses on the Flatten endpoint too, so treat that as the working name rather than what the table prints.

It's telling that PDF4me's own Fill a PDF Form documentation names Protect Document as the natural next step, not an alternative: "apply password protection and permissions after filling," recommended specifically for filled forms going out over email. That's the sequence the platform itself points toward, and it's worth testing both endpoints interactively before wiring them into a pipeline, through the Flatten PDF API Tester and the Protect Document API Tester, to see the request and response shape before any code gets written. Authentication for either endpoint follows the same Connect to the PDF4me V2 API pattern: an API key in the Authorization header, nothing exotic.

The three-step pattern, not a one-step shortcut

Put together, a filled document that genuinely needs to leave the building locked down runs through three separate operations, each doing one job:

Fill the form with the submitted data.
Flatten it (or set KeepPdfEditable: false during fill) so the visual record can't be casually refilled.
Protect it with a password and a pdfPermission value so it can't be opened, printed, or copied by anyone who shouldn't have it.

Skipping step three because step two already happened is the exact mistake this article opened with. Flattening is a formatting decision. Protecting is an access-control decision. A document can be flattened and wide open, or unflattened and locked down tight (Protect Document doesn't care whether the source PDF still has live form fields), and most real workflows want both, in that order, for different reasons.

The same gap exists in no-code workflows

None of this is unique to raw API calls. The same Flatten PDF operation is exposed as a dedicated module or node in Make, Power Automate, Zapier, and n8n, each one wrapping the identical REST call behind a visual drag-and-drop step. If a workflow builder drops a Flatten action at the end of a Fill Form scenario and calls it done, the resulting document has exactly the same access-control gap as the raw API version. No-code doesn't change what the endpoint does; it just makes it faster to skip the protection step by accident, since there's no error, no warning, and no failed request. The flatten succeeds every time, whether or not anything downstream actually needed it to.

The honest limit

None of this makes a flattened-and-protected PDF unbreakable. pdfPermission restrictions are enforced by compliant PDF readers, not by the file format itself, the same limitation every PDF permission system has always had. A password gates who can open the file; it does not gate what happens to the bytes after a determined reader ignores its own enforcement. For document distribution and archival, that's still a meaningfully higher bar than an unprotected flattened file sitting in an inbox, but it's worth knowing what the guarantee actually is before promising it to a compliance team.

The fix here isn't a new feature. It's reading past the name of the endpoint you're already calling, and asking what problem it was actually built to solve before assuming it solved a different one.

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

Rendering Pixel-Accurate PDFs From Raw HTML, No Headless Browser Required

PDF4me — Thu, 27 Aug 2026 18:18:24 +0000

If you've ever generated a PDF from HTML, you've probably met the headless browser. Puppeteer, Playwright, wkhtmltopdf, some flavor of Chromium running invisibly on a server somewhere, waiting to render a page and hand you back a PDF. It works. It also means you're now responsible for keeping a browser binary alive in production: patching it, sizing memory for it, restarting it when it silently hangs on a font that never loaded. That's a lot of infrastructure for what is, conceptually, a single conversion step.

PDF4me's Convert HTML to PDF endpoint skips that entirely. You send HTML, base64-encoded, to a single REST endpoint. PDF4me renders it server-side and hands back a finished PDF. No browser to install, no headless process to babysit. PDF4me's own Make integration page puts it plainly: the module "renders HTML content or a public web URL into a finished PDF document without a headless browser or extra rendering tools." That's the whole pitch, and it's a useful one if you've spent an afternoon debugging why a headless Chrome instance ran out of memory on a Friday.

What the endpoint actually takes

The REST call is POST /api/v2/ConvertHtmlToPdf. At minimum you're sending docContent (your HTML, base64-encoded), docName for the output file, and indexFilePath, which is where things get more useful than they first look. You're not limited to a single HTML file: PDF4me accepts a ZIP archive containing HTML plus its referenced assets (CSS files, images, fonts), and indexFilePath tells PDF4me which file inside that ZIP is the entry point. If your invoice template pulls in a separate stylesheet and a logo image, you don't need to inline everything into one file. Zip it, point PDF4me at the index page, done.

Here's a live-verified Python sample, adapted from PDF4me's own pdf4me-api-samples repo (MIT licensed):

import requests
import base64

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

with open("invoice.html", "rb") as f:
    html_base64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": html_base64,
    "docName": "output.pdf",
    "indexFilePath": "invoice.html",
    "layout": "Portrait",
    "format": "A4",
    "scale": 0.8,
    "topMargin": "40px",
    "bottomMargin": "40px",
    "leftMargin": "40px",
    "rightMargin": "40px",
    "printBackground": True,
    "displayHeaderFooter": True,
    "async": True
}

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

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

if response.status_code == 200:
    with open("output.pdf", "wb") as f:
        f.write(response.content)
elif response.status_code == 202:
    # Async: poll the Location header URL until it returns 200
    location_url = response.headers.get("Location")

Two things worth flagging here since I hit both while cross-checking the docs against the actual sample code. First, the real request payload sends a lowercase "async": true, while the API Tester for this same endpoint documents it as IsAsync. Second, the Convert HTML to PDF REST page's own text says scale runs "between 0 and 0.8," but the working sample code's own comment, the API Tester, and the sibling Convert URL to PDF page all agree on a 0.1 to 2.0 range where 1.0 is original size. If precise scaling matters, test the real boundary in the API Tester rather than trusting either doc page blindly.

Where your page dimensions actually come from

Here's the part that trips people up coming from a headless-browser mental model: layout only controls Portrait versus Landscape. It does not control page size, margins, or fonts by itself. Those come from the CSS inside your HTML. PDF4me's Make integration guide is direct about this: "Page dimensions and margins in the output PDF come entirely from the CSS in your HTML... the Layout dropdown only sets Portrait vs Landscape orientation." If you want a true A4 page with a 20mm margin, you write it into a style block with an @page rule, not into a PDF4me parameter.

That same guide surfaces a gotcha worth repeating because it will bite you exactly once and then never again: inline styles and embedded <style> blocks render reliably, but external stylesheets loaded via a <link> tag only work if PDF4me can reach that URL publicly at render time. If your CSS lives behind a login, a VPN, or a staging environment PDF4me's servers can't hit, your styling silently disappears from the output. No error, just a PDF that doesn't look like your preview. Inline it or embed it if you're not certain the link is public.

Same endpoint, four different shapes

The REST call is the mechanism. Each integration platform wraps it differently, and the differences matter for which one fits your stack.

Make gives you a two-field module: Document / public file URL accepts either binary HTML content from an earlier module or, notably, a live public web address directly. If the page you want already exists and is publicly reachable, you can skip building HTML entirely and just point Make at the URL.

Zapier keeps the same idea even simpler: map an HTML file, choose Portrait or Landscape, done. It's the thinnest wrapper of the four.

Power Automate mirrors the REST parameter set closely, including ZIP support with an index file path, which fits teams already pulling multi-file HTML templates out of SharePoint or OneDrive.

n8n is the most flexible of the four. Its node accepts four separate input types: Binary Data, Base64 String, raw HTML Code typed directly into the node, or a public URL. That HTML Code option is genuinely useful for quick internal tooling, you can write throwaway HTML straight into the workflow without a prior node generating it.

If you'd rather convert an already-live page directly instead of assembling HTML yourself, that's a different endpoint: Convert URL to PDF takes a web address plus optional authentication (Basic, OAuth, or API key) and handles the rest.

Try it before you write a line of code

Every parameter above is testable directly in the API Tester without writing a request by hand. Upload a file, fill the fields, hit send, and you get back either a 200 with the PDF, or a 202 with a Location header to poll if you set async processing on. That async path matters if your HTML is large or you're batching, since polling means you're not holding a connection open waiting on a synchronous render.

Why this is worth doing without a browser at all

Converting HTML to PDF is one of the more common document automation asks there is: invoices built from a template, weekly reports assembled from a database query, an email body archived as a compliance record. What changes when you route it through a rendering API instead of a headless browser is what you're no longer responsible for. No browser process to keep patched. No memory leak from a page that never finished loading. No debugging why a font rendered differently in your CI container than on your laptop. You send HTML and parameters, you get back a PDF.

That's the trade worth understanding before you reach for Puppeteer out of habit: a REST call has a fixed, documented parameter surface. Does a headless browser really need to be your default anymore?

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

Turning a Word Form Into a Fillable PDF Without Redesigning It

PDF4me — Wed, 26 Aug 2026 13:06:05 +0000

Somewhere in your company there is a Word document with a Developer tab open, a handful of content controls dropped in, and a name like intake-form-v4-FINAL.docx. It works fine, as long as everyone filling it out has Word. The moment you need to send it to a client, a candidate, or a customer who might be on a phone or a shared kiosk PC, "has Word" stops being a safe assumption. What they do have, almost without exception, is something that can open a PDF.

Convert Word to PDF Form exists for exactly that handoff. You are not redesigning the form. You are not rebuilding it field by field in a separate PDF form builder. You send the Word file you already built, and you get back a PDF where those same fields still work.

What the endpoint actually does

The REST API exposes one endpoint: POST /api/v2/ConvertWordToPdfForm. The request body needs two fields: docContent, the Word file as Base64, and docName, the output filename such as output.pdf. Live-verified against both the REST docs page and the official Python sample in the pdf4me-api-samples repo, which also sends a third field, async, and authenticates with Basic auth against api.pdf4me.com rather than the docs host:

import requests
import base64

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

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

payload = {
    "docContent": word_base64,
    "docName": "output.pdf",
    "async": True
}
headers = {
    "Authorization": f"Basic {api_key}",
    "Content-Type": "application/json"
}

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

if response.status_code == 200:
    with open("output.pdf", "wb") as f:
        f.write(response.content)
elif response.status_code == 202:
    # Async job accepted, poll response.headers["Location"] until 200
    pass

Worth flagging: the sample repo's own README describes the request as multipart/form-data, but the actual script it ships sends application/json, exactly like the REST docs page. The script is the one that runs, so that's the version to trust. The API Tester page for this endpoint also references an IsAsync flag rather than the lowercase async the working sample sends; if you're building this by hand rather than starting from the sample, test both field names against your own request in the API Tester before assuming either works.

Authentication otherwise works the same as every other PDF4me REST call: an API key from the PDF4me dashboard. If this is your first PDF4me endpoint, the connect-to-API guide covers the base URL and header format once, for every endpoint after this one.

What actually converts, and where the docs disagree with each other

This is worth reading carefully before you build anything on top of this. PDF4me's own documentation describes what this endpoint preserves in two noticeably different ways, and the more detailed of the two is the more conservative one.

The Make module page is the most specific source available, and it says plainly: the Word document must contain formal content controls inserted through Word's Developer tab, specifically Text controls, Check Box controls, and Drop-Down List controls. Text controls become PDF text input fields, checkboxes stay checkboxes, dropdown controls become PDF combo boxes. Everything else, meaning plain underlined blanks, table cells styled to look like a form, or regular body text, gets rendered as static, non-editable content in the output PDF. Make's own FAQ repeats this twice, in slightly different wording, which reads like a page written by someone who has actually watched this conversion fail on a form that only looked like it had fields.

The REST API page and the Zapier action page, by contrast, both list a longer set of "advanced controls" the endpoint supposedly preserves: rich text fields, file upload fields, calculation fields, digital signature fields, and combo boxes, on top of the standard text, checkbox, dropdown, and date picker set. Neither page explains how you would author a "calculation field" as a native Word content control, and Make's own documentation, which is otherwise the most thorough of the four integration pages, never mentions any of them. Given that the request payload itself is only docContent, docName, and async, there is no parameter that would let you configure which control types to preserve. The most defensible read: the endpoint reliably handles Word's standard content controls, text, checkbox, dropdown, and date picker, and the "advanced controls" list on the REST and Zapier pages describes a broader ambition than a plain Word content control can actually represent. If your form needs something more exotic, test it through the API Tester before you build a workflow around it.

One more distinction worth having straight: this conversion keeps form fields interactive. It does not flatten them. If you need a locked, non-editable copy for archiving or after a signature is collected, that's a separate step, Flatten PDF, chained after this one.

Four ways to put this in a workflow

Make. The Convert Word to PDF Form module needs only a Connection, File Name, and the Document binary. No optional parameters exist. Map File Name with its .docx or .doc extension intact, since that's how the engine identifies the source format, and map Document from whatever preceding module downloaded or generated the file. A typical scenario: a new client record triggers the scenario, Dropbox downloads the intake form template, this module converts it, and Gmail emails the fillable PDF to the client. Chain a Fill PDF Form module afterward to pre-populate any fields, such as a client's name or an event date, before the recipient ever opens it.

Zapier. The Convert Word to PDF Form action takes File Content and File Name as its only required fields, and returns File Content, File Name, File URL, Job Id, and Trace Id. A Zap here might trigger the moment a new Word application form is finalized in Google Drive, convert it, and route the resulting PDF to an applicant tracking system or an email step. Zapier's own tips page is blunt about the most common failure mode: a Word document with underlines or boxed table cells styled to look like a form has nothing for this action to actually preserve, since none of that is a real content control.

Power Automate. The Convert Word to PDF Form action fits naturally into a Microsoft 365 flow: File Content (binary) and File Name are both required, and the connector accepts sources directly from SharePoint or OneDrive. This is a natural fit for HR onboarding paperwork or benefits enrollment forms that already live in a SharePoint library: retrieve the Word template, convert it, and route the resulting fillable PDF to the employee or applicant without anyone touching Word.

n8n. The Convert Word to PDF Form node is the most flexible of the four on input handling. It accepts Binary Data, a Base64 string, or a public URL as the source, useful if your Word templates live somewhere you'd rather reference directly than download through an extra node first. Input File Name, Output File Name, and a Binary Data Output Name are required; an Advanced Options section adds a Custom Profiles field for JSON-based configuration, and the documented example includes a preserveFormFields flag alongside outputDataFormat. Since the base REST payload has no equivalent parameter, treat that flag as n8n-specific until you've confirmed what it changes for your own document. The response comes back with a success boolean, an operation field, and a human-readable message, structured enough to build real error handling around instead of guessing from an HTTP status code alone.

Test it before you automate it

Before wiring this into any of the four platforms above, it's worth confirming the request shape and the actual conversion behavior directly. The Convert Word to PDF Form page in the API Tester lets you send your API key and a Base64 Word document and see the response in the browser, no code required. It's the fastest way to find out, on your own form, whether every content control you expect to survive actually does, before that question surfaces three steps deep in a Make scenario you have to unwind to debug.

What this replaces

The alternative to this endpoint is not usually "no fillable PDF." It's a second, parallel form built by hand in a dedicated PDF form tool, disconnected from the Word document someone in HR, legal, or sales is still the one actually maintaining. Every time that Word template changes, someone has to remember to rebuild the PDF version too, or the two quietly drift apart. Converting from the Word source directly means the form template has exactly one place to live.

One honest gap worth flagging: PDF4me doesn't yet have a dedicated blog walkthrough for this specific endpoint, so beyond the reference docs and the sample repo linked above, that repo is currently the most complete worked example available.

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

Markdown In, PDF Out: A Docs-as-Code Pipeline in One API Call

PDF4me — Tue, 25 Aug 2026 07:59:56 +0000

Every team that writes docs-as-code eventually hits the same wall. Your README lives in Markdown. Your changelog lives in Markdown. Your architecture notes, your onboarding guide, your API reference, all Markdown, all sitting next to the code where version control can track every change. Then someone in legal, procurement, or a client's IT department asks for "the documentation" and means a PDF. Not a GitHub link. Not a rendered HTML page. A file they can attach to an email, print, or archive.

That request used to mean opening a Markdown file in some GUI tool, exporting it by hand, and doing it again next release. Convert Markdown to PDF turns that into a single REST call, which means it turns into a step in a pipeline instead of a chore on someone's calendar.

What the endpoint actually does

The REST API exposes one endpoint for this: POST /api/v2/ConvertMdToPdf against the base URL https://api.pdf4me.com, per the Connect to PDF4me API guide.

Two parameters are required: File Content, the Markdown file encoded as Base64, and File Name, the source filename with its extension, for example document.md. There's one optional parameter, Markdown File Path, which only matters if you're sending a ZIP archive instead of a single file. If your input is a ZIP of Markdown files, this field tells PDF4me which file inside the archive to render, something like docs/readme.md. Leave it empty for a direct .md file.

The JSON payload uses docContent for the Base64 source, docName for the output name, and mdFilePath for the in-archive path when relevant, alongside IsAsync for polling behavior on larger files. Send those fields with your API key in the Authorization header, and the response comes back with the converted file content and name, ready to save, attach, or pipe into the next step.

What actually gets preserved matters more than the endpoint shape. The conversion handles the Markdown syntax that documentation is actually built from: headers from H1 through H6 with correct hierarchy, bold, italic, strikethrough, and inline code, ordered and unordered lists with proper nesting, fenced code blocks with syntax highlighting, links, embedded images, and tables with column alignment intact. That's the difference between a PDF that looks like documentation and one that looks like a wall of plain text with stray asterisks in it.

A minimal working request

Here's the shape of a real call, field names verified against the live docs page and the API Tester's own quick reference:

import base64
import requests

with open("README.md", "rb") as f:
    md_base64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": md_base64,
    "docName": "README.md",
    "mdFilePath": "",       # only needed when docContent is a ZIP
    "IsAsync": False
}

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

response = requests.post(
    "https://api.pdf4me.com/api/v2/ConvertMdToPdf",
    json=payload,
    headers=headers
)

if response.status_code == 200:
    with open("README.pdf", "wb") as out:
        out.write(response.content)
elif response.status_code == 202:
    # large file, poll the Location header until it returns 200
    poll_url = response.headers["Location"]
else:
    print(response.status_code, response.text)

A quick note on the docs page itself: the generic payload example shown there (docName: "output.pdf") is boilerplate shared across every Convert endpoint's page and doesn't match this endpoint's own parameter table, which is explicit that File Name is the source Markdown filename, not the output PDF name. The API Tester's quick reference confirms the real field set: api-key, docContent, docName, mdFilePath, IsAsync. Trust the parameter table and the tester over the boilerplate example if you ever see the two disagree.

Status 200 means the PDF came back in the response body immediately. Status 202 means PDF4me accepted the job and is processing it asynchronously. On the API Tester's live page for this endpoint, setting IsAsync to true is exactly how you'd trigger that path for a larger file, then poll the Location header URL until it resolves.

Batch conversion, not just one file at a time

Documentation rarely lives as a single file. A docs folder might hold dozens of .md files: guides, references, changelogs, contributing notes. The endpoint's ZIP support exists for exactly this. Send a ZIP archive as the file content, and use Markdown File Path to point at the specific file inside it you want rendered for that call. To convert an entire folder, you run the endpoint once per file, which is precisely the kind of repetitive step a workflow tool should own instead of a person.

Four ways to wire it into a pipeline

A docs-as-code pipeline generally looks the same regardless of which automation tool sits in the middle: something triggers on a documentation change, the Markdown gets fetched, PDF4me converts it, and the PDF lands somewhere a human or a customer can find it. Here's what that looks like on each platform PDF4me supports.

Make. The Convert Markdown to PDF module takes a Connection, File Name, Document (the binary buffer), and conditionally Markdown File Path for ZIP input. It maps cleanly onto a scenario that triggers on a new GitHub release, downloads the README, converts it, and attaches the result to the release assets. Two things worth knowing before you build this: relative image paths in your Markdown may not resolve when the module renders the PDF, so use absolute URLs for embedded images, and the module converts one file per run, so processing a full docs folder means placing a Repeater or Iterator ahead of it. Make's own docs note the module follows the CommonMark spec, with GitHub-flavored extensions like tables and task lists handled per GitHub's Markdown guide.

Zapier. The Markdown To PDF action takes File Name and File Content as required fields, with Markdown File Path again reserved for ZIP input, and returns a direct URL to the converted PDF alongside the filename and extension. A typical Zap here triggers when documentation updates in a GitHub repository, retrieves the latest Markdown files, converts each one, and can chain into watermarking, packaging, and publishing steps before notifying a channel or customer list that new docs are live.

Power Automate. The Convert Markdown To PDF action fits naturally into a Microsoft 365 flow: File Content and Input File Name are required, Markdown File Path is conditional on ZIP input, and the output comes back as binary File Content plus File Name ready to drop into SharePoint, attach to an Outlook email, or archive in OneDrive. This is the natural home for a flow that watches a SharePoint documentation library, converts new or updated .md files, and routes the PDF to stakeholders without anyone touching Word.

n8n. The Convert Markdown to PDF node is the most flexible of the four on input handling: it accepts Binary Data, a Base64 string, or a public URL as the Markdown source, which matters if your documentation lives somewhere you'd rather point at than download through an extra node. Document Name, Output File Name, and Output Binary Field Name are required; an Advanced Options section adds Custom Profiles for JSON-based configuration like outputDataFormat. The response includes not just the file but a success boolean and a message field, which is the kind of structured signal that makes error handling in a longer workflow far less guesswork.

What a full pipeline looks like end to end

Put the pieces together and a docs-as-code-to-PDF pipeline looks roughly like this: a trigger fires on a documentation change, whether that's a GitHub release, a SharePoint file update, or a scheduled batch job. The relevant Markdown file, or a ZIP of several, gets fetched. PDF4me converts it, preserving headers, code blocks, tables, and links exactly as they were written. From there the PDF can be watermarked with a version number, merged with other converted files into a single package, and pushed to wherever it needs to land: a customer portal, an email attachment, a documentation archive, or all three.

None of this requires anyone to open a Markdown-to-PDF desktop tool ever again. The source of truth stays in version control, in Markdown, exactly where a docs-as-code workflow wants it, and the PDF becomes a generated artifact instead of a manually maintained parallel copy that drifts out of sync the first time someone forgets to update it.

One honest gap worth flagging: PDF4me doesn't yet have a dedicated blog walkthrough for this specific endpoint, so if you're looking for a worked example beyond the reference docs and code samples linked above, the GitHub samples repository is currently the most complete place to start, alongside the interactive API Tester for trying a request before you write any code at all.

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

Testing Every PDF4me Endpoint Before You Write a Line of Integration Code

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

You open a docs page for an endpoint you have never called, read the parameter table once, and start writing the request body from memory. Which field takes the file, docContent or file? Does the filename go in a separate field, and does the extension actually matter, or is that just convention? You send the request. It comes back 401. Not because your logic is wrong. Because you guessed at one header and guessed wrong.

That twenty minutes is the tax every developer pays the first time they touch a new API, and it has nothing to do with how good the documentation is. Reading about a request and sending one are different skills. PDF4me's answer to that gap is the Interactive API Tester, and the useful thing about it is not that it exists. It is that there is a dedicated page for every single endpoint, not one generic form you have to reconfigure each time.

One tool, 78 pages, zero code

Most API explorers give you a single generic interface and expect you to know which fields matter for the operation you are running. PDF4me's tester inverts that. There are 78 endpoint-specific pages, each one already built around the exact inputs that one action expects. Want to see what Parse Document actually returns for a real invoice? There is a page for exactly that, not a generic call-any-endpoint console you have to configure from scratch. Want to check how Merge Multiple PDF Files behaves when you throw three files at it instead of two? Same story. Add Barcode to PDF and Fill PDF Form each have their own dedicated form too.

Every page follows the same shape. Upload the source file, fill in the parameters through dropdowns and text fields instead of hand-typing JSON, submit, and watch the response come back in real time: the processed output file, ready to download, alongside the raw JSON response and the HTTP status code the server actually returned. You are not reading a static example response copied into a docs page months ago. You are looking at what the API does with your file, right now.

What it's actually good for

The docs describe five concrete uses, and they map to five real moments in a build.

Verifying behavior before you write a line of integration code. You know exactly what a response looks like before you write a single line of parsing logic against it, instead of discovering the shape of the JSON after your code already assumes something different.

Testing edge cases on purpose. Password-protected files, unusually large uploads, specific page ranges. These are the inputs that tend to surface bugs weeks after launch, precisely because nobody tried them during development. Trying them here costs nothing but a few minutes.

Exploring which parameters produce which output. Some parameters are easier to see the effect of than to read about. Watermark opacity, compression profile, page range syntax. Changing a value and immediately seeing the result beats re-reading a parameter description three times.

Debugging by comparing expected versus actual. If your production integration returns something you did not expect, running the identical operation through the tester isolates the variable. Is the API behaving differently than you assumed, or is the bug in your own request construction? The tester answers that in one request.

Demonstrating capability without writing anything. A working demo for a stakeholder, a proof of concept for a teammate deciding whether an endpoint fits their use case. None of that requires a sandbox environment or a single line of integration code.

From the tester to real code

The tester is a bridge, not a destination. Once you have confirmed an endpoint does what you need, the next step is wiring it into your own application, and the Connect to the PDF4me V2 API reference is what you translate that confirmation into. The contract is consistent across the whole API: every endpoint is a POST request to https://api.pdf4me.com, with a JSON body, an Authorization header carrying your API key, and file content sent as a Base64 string in a docContent field. The docName field is not cosmetic. It carries the file extension, and that extension is part of what the request needs to process the file correctly.

Here is what that looks like for Convert to PDF, taken directly from the live request example on its docs page:

POST https://api.pdf4me.com/api/v2/ConvertToPdf
Content-Type: application/json
Authorization: YOUR_API_KEY

{
  "docContent": "<base64 content of a .docx, .pptx, .xlsx, or image file>",
  "docName": "output"
}

And here is the same shape for Get PDF Metadata, a different endpoint entirely, using the same two required fields:

{
  "docContent": "<base64 content of the PDF>",
  "docName": "output.pdf"
}

Same two fields, same header pattern, different endpoint path and a completely different response shape on the way back. That consistency is exactly why testing five different endpoints in the browser first is worth the time: you are not learning five different request formats, you are confirming the same format works for five different jobs, and catching the field-level details specific to each one along the way.

Getting to that first authenticated request starts at Getting Started with the API Portal: register, activate access to your key, and open the dashboard to copy it. The tester and your eventual integration code authenticate the exact same way. Nothing changes when you move from one to the other except that you are now writing the request instead of filling in a form.

Where testing in the browser catches the gap early

That 401 from the opening scenario is not hypothetical. A missing, malformed, or revoked API key produces exactly that response, and PDF4me's own 401 Unauthorized troubleshooting page exists because it is one of the most common ways a first integration attempt goes wrong. Hit that error inside the tester, where the only variable is the key you pasted into a form field, and it takes seconds to fix. Hit it three layers deep inside application code you just wrote, where the bug could be your header construction, your encoding, your key rotation logic, or the request body itself, and it takes a lot longer to isolate.

That is the actual value on offer here. Not that the tester replaces writing code. It never will, and it is not built to run load tests, chain multiple endpoints into a workflow, or serve as a regression suite for your CI pipeline. Those are jobs for your own test harness, or for a no-code platform if the workflow itself belongs in Zapier, Make, Power Automate, or n8n rather than custom code. What the tester does is remove the guessing from the first contact with an endpoint, so the code you eventually write is built against something you have actually seen work, not something you assumed would.

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

Teaching 70+ Coding Agents the Right PDF4me Endpoint for the Job

PDF4me — Mon, 24 Aug 2026 10:44:12 +0000

Ask a coding agent to "compress this PDF using the PDF4me API" and it will happily write you something. Whether that something is correct is a different question. Most general-purpose coding assistants have never seen PDF4me's actual endpoint list, its auth header format, or the shape of a real request body, so they guess. Sometimes the guess is close. Sometimes it invents a parameter that does not exist, or routes a compression request to a conversion endpoint because the names sound similar.

PDF4me Agent Skills exist to close that gap. A skill is an installable package that teaches an AI coding assistant, directly and specifically, how the PDF4me REST API actually works: which endpoint handles which job, what the auth convention looks like, what a payload is supposed to contain. Instead of a model reconstructing that from training data, it reads it from a reference file sitting in your own project.

What a skill actually is

The current skill, pdf4me-api, is hosted on GitHub at github.com/pdf4me/pdf4me-skills. Live-checking the repo itself (not just the docs page) surfaces the exact skill structure:

skills/pdf4me-api/SKILL.md         # manifest, routing, and usage guidance
skills/pdf4me-api/references/      # API reference notes grouped by feature area
skills/pdf4me-api/scripts/         # executable helpers for common flows

When you ask your agent to write PDF4me integration code, it consults these references before it writes a line, the same way a careful developer would open the docs before guessing at a parameter name. The skill covers PDF, Word, Excel, and image processing tasks through the REST API: conversion, editing, merge and split, OCR, extraction, generation, barcode, forms, and security operations.

Two ways to install it, verified against the live repo

The docs page and the repo's own README describe installation slightly differently, and the repo is the more current source. Two paths exist, and which one you use depends on which agent you run.

Claude Code, via the plugin marketplace:

/plugin marketplace add pdf4me/pdf4me-skills
/plugin install pdf4me@pdf4me-plugin
/reload-plugins

Invoke it explicitly afterward with /pdf4me:pdf4me-api, or describe a PDF4me task and let Claude Code trigger it automatically. You can also try the skill without installing anything, using claude --plugin-dir /path/to/pdf4me-skills.

Codex, Cursor, GitHub Copilot, Cline, Gemini CLI, Windsurf, Zed, and 70+ other agents, via the npx skills CLI:

npx skills add https://github.com/pdf4me/pdf4me-skills.git --skill pdf4me-api

That command opens an interactive picker: select which installed agents should receive the skill, choose project or global scope, and pick an installation method. Symlink installation is worth choosing deliberately, since it makes future updates to the skill's reference files propagate automatically instead of leaving you on a stale copy. Under project scope, the files land at .agents/skills/pdf4me-api/, checked into your repo like any other project asset your team and your agent both read. In Codex specifically, invoke the skill explicitly with $pdf4me-api, or let Codex select it automatically from a plain-language request.

That 70-plus figure is not marketing shorthand. It reflects how many coding tools the npx skills CLI has adapters for. If your team runs five different agents across five different engineers, one install command handles all of them instead of five separate integration writeups.

What the agent actually gets

This is what turns "compress this PDF" from a guess into a grounded answer. The skill documents endpoint routing, auth conventions, and payload shapes, category by category. This matters more than it sounds like it should, because PDF4me's REST API spans a genuinely wide surface, with separate endpoint families and their own request shapes for each category. A generalist coding agent with no grounding will, at best, get the common cases right and quietly misfire on the rest.

The auth convention itself: every request needs an Authorization: Basic <api_key> header. The skill documents this format but does not store or transmit your key. That key comes from the PDF4me API dashboard, the same place covered in Getting Started with the PDF4me API Portal for anyone setting up an account for the first time. The underlying reference both the skill and this section are built on is Connect to the PDF4me V2 API, which documents the base URL (https://api.pdf4me.com), the POST /api/v2/ endpoint pattern, and the full response-code table, live-confirmed while writing this piece.

Skills versus MCP, briefly

If you followed this cluster's earlier piece on wiring PDF4me's MCP server into Cursor, VS Code, Claude Desktop, and Windsurf, the natural question is which mechanism to reach for. MCP exposes live callable tools an agent invokes directly during a chat session. Agent Skills load static, structured guidance the agent reads and then writes its own code from, whether that is a curl command, a Python script, or a full integration module. Use Agent Skills when the assistant should generate REST API code, curl, or scripts. Use MCP when the client should call PDF4me tools directly during the conversation. Both can be installed together, and a developer who wants an agent that can both call PDF4me live and also write standalone integration code has a real reason to run both at once.

Closing the loop before you ship

Once your agent, guided by the skill, generates a request against a PDF4me endpoint, you do not have to trust it blind. The Interactive API Tester is a form-based, no-code way to fire the exact same endpoint yourself: upload a source file, set the parameters the agent's generated code claims to be setting, and compare what actually comes back against what the agent told you to expect. It is a fast way to catch a subtly wrong parameter before it ships inside a production integration, and it works whether or not you trust the code the agent just handed you.

The honest limit

Agent Skills teach an assistant how the API is shaped. They do not replace testing, and they do not guarantee the model applies the guidance correctly every time, particularly on edge cases the reference files describe briefly rather than exhaustively. Treat generated code the way you would treat a capable but new engineer's first draft: probably closer to right than a guess from nothing, still worth a second look before it touches production data. For a team running several different coding agents, the alternative, each engineer's agent independently guessing at the same wide API surface, is a worse starting point than one shared, versioned reference every agent reads from the same place.

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

Dead Links Inside a Generated PDF, Repointed Without Rebuilding the File

PDF4me — Sun, 23 Aug 2026 21:36:48 +0000

Somewhere in your document pipeline right now, there's a PDF with a hyperlink pointing at the wrong place. A "Pay Now" button on an invoice that still points at a staging checkout URL from three environments ago. A "View your policy" link in a generated insurance document that points at a page your CMS retired last quarter. A partner portal link that worked fine at generation time and now 404s, because whoever owns that redirect changed it without telling anyone who touches your documents.

None of this is rare. It's what happens when links get baked into a document at generation time and nobody revisits them after the fact. The document itself is fine. Every other field is correct. But the one clickable thing a reader might actually act on sends them somewhere wrong, and by the time someone notices, hundreds or thousands of copies are already sitting in inboxes.

The instinct that wastes an afternoon

The obvious fix is to regenerate the document. Pull the source data, fix the URL in the template, re-run the generation job, redistribute. That works if you still have the source, the template hasn't drifted, and you're only fixing one document. It stops working the moment any of those conditions fail: the source system has moved on, the template that produced this specific batch is three versions old, or you're staring at ten thousand PDFs that were generated correctly at the time and just need one link swapped everywhere.

Regenerating from source treats the symptom as if it were the whole document. It isn't. The text, the layout, the compliance boilerplate, the signature block, all of that is correct and doesn't need to change. The only thing wrong is a target URL sitting underneath a clickable region. Rebuilding an entire file to fix one pointer is a lot of blast radius for a small, well-defined problem.

What's actually broken: the annotation layer, not the document

A hyperlink in a PDF isn't part of the visible text. It's a separate object, a link annotation, that PDF viewers overlay on a region of the page and route to a target when clicked. The text underneath can say "Pay Now" or "View your policy" and never change; the annotation is what decides where the click actually goes. That separation is what makes a targeted fix possible: you can update where a link points, or the display text tied to it, without touching a single pixel of the rendered page.

That's what PDF4me's Update Hyperlink Annotation endpoint does. It operates on the annotation layer directly, changing hyperlink text, the destination URL, or both, in an existing PDF. No source template, no regeneration, no re-rendering the page.

The endpoint, verified

The REST endpoint is a single POST call:

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

Each hyperlink change is described by a SearchOn/SearchValue pair that identifies the target, plus the current and new values for both the display text and the URL:

{
  "docName": "output.pdf",
  "docContent": "JVBERi...",
  "updatehyperlinkannotationlist": [
    {
      "SearchOn": "Text",
      "SearchValue": "http://www.google.com",
      "IsExpression": true,
      "TextCurrentValue": "http://www.google.com",
      "TextNewValue": "https://pdf4me.com",
      "URLCurrentValue": "http://www.google.com",
      "URLNewValue": "https://pdf4me.com"
    }
  ],
  "async": true
}

updatehyperlinkannotationlist takes an array, so one call can carry as many corrections as a document needs, each with its own search target and its own current/new text and URL pair. That's the batch-correction case from a single request: fix every stale link in a document, or across a set of documents, in one pass instead of one-by-one.

A quick verification note, because it's worth naming when it happens: PDF4me's official Python sample for this endpoint (in pdf4me-api-samples) confirms the endpoint path exactly as shown above, singular UpdateHyperlinkAnnotation, matching the live docs page. That repo's own README describes a different payload shape (a plural endpoint name and separate hyperlinks/annotations arrays) that doesn't match either the live docs page or the actual .py script sitting next to it, only the README text is off. The code sample and the docs page agree with each other; this article follows those two, not the README.

Here's the working Python call, trimmed from that sample:

import base64
import requests

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

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

payload = {
    "docName": "output.pdf",
    "docContent": base64_content,
    "updatehyperlinkannotationlist": [
        {
            "SearchOn": "Text",
            "SearchValue": "http://www.google.com",
            "IsExpression": True,
            "TextCurrentValue": "http://www.google.com",
            "TextNewValue": "https://pdf4me.com",
            "URLCurrentValue": "http://www.google.com",
            "URLNewValue": "https://pdf4me.com"
        }
    ],
    "async": True
}

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

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

if response.status_code == 200:
    # Synchronous: binary PDF content comes back directly
    with open("hyperlinks_updated_PDF_output.pdf", "wb") as out:
        out.write(response.content)
elif response.status_code == 202:
    # Asynchronous: poll the Location header until the job finishes
    location_url = response.headers.get("Location")

A 200 response hands back the corrected PDF's binary content directly. A 202 means the job is processing asynchronously, useful for larger files or batches, and the response carries a Location header to poll until it's done. Same shape developers will recognize from other PDF4me endpoints: fast documents resolve inline, heavier jobs hand you a job to check on.

Where this fires in a real pipeline

Three shapes of this problem show up constantly once you start looking for them.

Domain migrations are the most common. A company moves its customer portal from one domain to another, or a marketing team reworks a URL structure for SEO reasons, and every previously generated document that linked to the old structure is now technically broken, even though nothing about the document itself changed. Nobody wants to regenerate a year of historical invoices because the checkout domain moved.

Redirect rot is the quiet version of the same problem. A link worked at generation time because it pointed at a redirect, and the redirect target changed later, or got removed entirely. The document was correct when it was made. It just didn't stay correct, because the thing it depended on wasn't under the document's control.

Batch correction is the operational version: you generated a thousand documents overnight, a QA pass the next morning catches that one link across the whole batch points at the wrong place, and you need to fix that one link on every file without touching anything else on any of them. Rebuilding a thousand documents from source to fix one URL is the kind of afternoon nobody wants, and it's exactly what the array-based payload above is built for.

How each low-code surface exposes it

If you'd rather try the endpoint against a real document before wiring it into code, PDF4me's interactive API Tester runs it directly in the browser, useful for confirming your search values and matching logic before either becomes part of a pipeline.

For no-code and low-code builds, Make, Zapier, and n8n each expose this as its own node. Make frames it as a batch link editor: search for link text or a URL inside a scenario and replace it, which is exactly the shape a domain-migration or redirect-cleanup job takes. Zapier's equivalent is described the same way, a batch link editor for searching and replacing link text or URLs across a Zap. n8n's Update Hyperlinks Annotation node does the same job inside a workflow, modifying existing hyperlink annotations by text, URL, or both, which slots naturally into a document-correction workflow that's already watching a folder or a webhook for new files.

Worth naming honestly: as of this writing, there's no Power Automate page for this specific endpoint in PDF4me's documentation. If your pipeline runs on Power Automate, this capability isn't available there the way it is on Make, Zapier, and n8n. That's a real gap, not an oversight in this article, and worth checking PDF4me's Power Automate integration guides directly if this is a blocker for your stack, since integration coverage does expand over time.

What this doesn't solve

It's worth being precise about the boundary here, because it's easy to conflate adjacent problems. Update Hyperlink Annotation changes real link annotations, the clickable objects PDF viewers recognize as links. It does not turn plain text that merely looks like a URL into a clickable one, and it doesn't touch a hyperlink that was flattened into the page during rendering rather than kept as a live annotation.

If what you actually need is to add a brand-new clickable link to text that currently has none, that's a different job: creating hyperlinks in a PDF via Make or the equivalent in Zapier, not updating one. And if the goal is auditing what's already there before deciding what to fix, PDF4me's link extraction tools in Make and Zapier pull every hyperlink out of a document as structured data, URL, link text, and page number, exactly what you'd run first across a batch before deciding which links actually need repointing.

Check the link layer before you touch the source

The habit worth building is small but easy to skip under pressure: before regenerating anything, ask whether the actual problem lives on the annotation layer. If a document is correct except for where one link points, the fix is narrower than rebuilding the file, and it scales to a thousand documents exactly as easily as it scales to one. Get started with connecting to the PDF4me API if you're wiring this into your own code, or reach for whichever automation platform already runs your document pipeline. Either way, fix the problem at the layer where it actually lives.

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

Reading a Swiss QR Bill Back Into Structured Payment Data

PDF4me — Fri, 21 Aug 2026 16:11:24 +0000

Somewhere in a finance team's inbox is a supplier invoice with a Swiss QR bill at the bottom of it. Since Switzerland's QR-bill standard took effect, every Swiss payment slip looks like this: a QR code sitting under a printed block of IBAN, amount, and reference details, replacing the old red and orange slips entirely. It is a clean, standardized format. It is also, for whoever has to get that data into accounting software, still a QR code someone scans, reads, and retypes by hand. Standardizing the printed layout solved a printing problem. It did not solve a data-entry problem, because scanning a QR code and understanding what it means are two very different things.

That gap is where most Swiss QR bill automation attempts stall. A generic QR scanner decodes the code fine and hands back a wall of text, because a Swiss QR bill does not encode a URL or a short string the way a marketing poster does. It encodes the Swiss Payments Code: a strict, multi-line data block carrying the creditor's IBAN, the payment amount and currency, a reference number, and more, all packed into a specific line order defined by the Swiss payment standard. Read that with a generic decoder and what comes back is technically correct and practically useless, a blob of text with no keys and no structure that still needs a second parsing layer written by hand.

What the endpoint actually returns

PDF4me's Read Swiss QR Code endpoint skips that second layer entirely.

POST /api/v2/ReadSwissQRBill takes a base64-encoded PDF and decodes the embedded QR bill directly into structured payment data as a JSON object, not a raw text dump. Three fields go in: docContent (the base64 PDF), docName (the filename), and async (true for larger batches, using the standard 202-plus-polling pattern). What comes back, once decoded, is a swissQrCodeData object with the fields a finance workflow actually needs already separated: amount, currency, iban, creditorName, paymentReference, plus dueDate and purpose when the bill carries them.

{
  "fileName": "invoice.pdf",
  "mimeType": "application/pdf",
  "fileSize": 2456789,
  "success": true,
  "swissQrCodeData": {
    "amount": "100.00",
    "currency": "CHF",
    "iban": "CH9300762011623852957",
    "creditorName": "Swiss Company AG",
    "paymentReference": "INV-2024-001",
    "dueDate": "2024-12-31",
    "purpose": "Invoice payment"
  }
}

That distinction matters more than it sounds like it should. PDF4me also has a general-purpose Read Barcode from PDF endpoint, and it is tempting to assume one barcode reader should handle every barcode. It will read the QR code's raw payload just fine. What it will not do is know that one block of that payload is the creditor's IBAN and another is the reference number, or that the reference needs different handling depending on whether it is a QR reference or a Creditor Reference under ISO 11649. Read Swiss QR Code exists specifically because that interpretation layer is the actual work, and it is not worth repeating by hand in every integration a team builds.

A working example

Here is the request in Python, adapted from PDF4me's official sample repository:

import os
import base64
import requests
import time

api_key = "YOUR_API_KEY"  # from https://dev.pdf4me.com/dashboard/#/api-keys/
pdf_file_path = "invoice.pdf"

url = "https://api.pdf4me.com/api/v2/ReadSwissQRBill"

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

payload = {
    "docContent": pdf_base64,
    "docName": os.path.basename(pdf_file_path),
    "async": True
}
headers = {
    "Authorization": f"Basic {api_key}",
    "Content-Type": "application/json"
}

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

if response.status_code == 200:
    print(response.json()["swissQrCodeData"])
elif response.status_code == 202:
    # Async: poll the Location header until it returns 200
    location_url = response.headers.get("Location")
    for _ in range(20):
        time.sleep(10)
        poll = requests.get(location_url, headers=headers)
        if poll.status_code == 200:
            print(poll.json()["swissQrCodeData"])
            break
else:
    print(f"Error: {response.status_code} - {response.text}")

The async branch matters more here than it does for most PDF4me endpoints. Swiss QR recognition can take longer than a standard barcode read, and the official sample uses an extended 20-retry, 10-second polling loop specifically because of that, not as boilerplate copied from another endpoint.

Where this fits in an accounts payable pipeline

The realistic entry point for this endpoint is a folder, not a single file. Invoices land in a shared Dropbox, SharePoint, or email inbox, each one a PDF with a Swiss QR bill on it, arriving on no predictable schedule. Wiring Read Swiss QR Code into that intake point means every incoming invoice gets its payment data extracted automatically, at the moment it arrives, instead of sitting in a queue for someone to open and transcribe. PDF4me's own workflow write-ups show this pattern in practice: reading the creditor and reference straight out of a QR-bill PDF to auto-rename the file for filing, on Make, Zapier, and n8n, so the manual "open PDF, find the reference number, type it into the ERP" step disappears from the process rather than getting faster.

The same extracted data closes the loop the other direction too. A business that generates its own Swiss QR bills with PDF4me's Create Swiss QR Bill endpoint can verify what actually printed by reading it back with this endpoint, useful as a sanity check before a batch of invoices goes out the door. And for teams processing invoice batches that arrive as one long combined PDF rather than individual files, Split PDF by Swiss QR uses the same QR-bill boundary to break a multi-invoice batch into individual documents before extraction even starts, so the reading step operates on one invoice at a time instead of hunting for boundaries inside a combined file.

Wiring it into a no-code workflow

None of this requires custom backend code to reach production. In Make, Read Swiss QR Code is a scenario module that takes a watched file and returns the decoded payment fields directly into the scenario's data flow, ready to route into a Google Sheet, a database module, or a rename-and-file step. In Zapier, the same extraction runs as a Zap step, triggered the moment a new file lands in a watched Dropbox or Drive folder, with the creditor, IBAN, amount, and reference coming back as fields a downstream Zap step can act on without a separate parsing action. In Power Automate, it slots into a flow the same way, a natural fit for finance teams already running approval or filing flows on Microsoft's automation stack. In n8n, it becomes a node inside a self-hosted workflow a team owns end to end, useful where the extracted data needs to feed a custom or internal accounting system.

Across all four, the shape of the workflow is the same: a file appears, its payment data comes out as structured fields a few seconds later, and nobody has opened the PDF to read it themselves. Not that reading one QR bill by hand is slow, it takes seconds, but that it is one more manual step in a chain that was supposed to run without a person watching it, and every manual step in that chain is a place invoices get delayed, misfiled, or mistyped.

Seeing it before writing a line of integration code

Before wiring this into a production flow, it helps to see the real output. The API Tester runs Read Swiss QR Code directly in the browser: upload a QR-bill PDF, call the endpoint, and see the actual structured JSON response, field names and all, before writing any integration code against it. Getting authenticated against the API in the first place is covered in Connect to the PDF4me V2 API, which lays out the base URL, headers, and request format the code sample above builds on.

The honest limit

This endpoint reads Swiss QR bills. It is built against the Swiss Payments Code standard specifically, not a general-purpose payment-QR decoder for every country's invoicing format. A business handling SEPA or other regional payment QR formats alongside Swiss ones needs to treat those as separate extraction problems, not assume one endpoint covers all of them. Within its actual scope, though, the value is specific and unglamorous in the best way: a field that used to require a human to look at a QR code and know what a Swiss Payments Code block means now arrives as JSON, and the person who used to retype IBANs from scanned invoices gets to stop doing that particular part of their job.

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