DEV Community: PDF4me

How to Remove a Password From a Protected Excel File via API

PDF4me — Mon, 12 Oct 2026 05:59:08 +0000

How to Remove a Password From a Protected Excel File via API

Somebody in finance sends you a nightly export. It's encrypted, because of course it is, their IT policy requires it, and the password lives in a shared vault your automation already has access to. Your pipeline grabs the file, and then just sits there, because every downstream step you've built, reading rows, merging workbooks, extracting a worksheet, expects a plain, unprotected .xlsx. A password-protected file isn't a smaller version of the same problem. It's a different file format as far as your code is concerned, and the first thing any automation touching it has to do is take the lock off.

Why a protected workbook breaks more than you'd expect

Excel password protection isn't one setting. A workbook can be locked at the file level, so it needs a password just to open at all, at the workbook level, so nobody can add, delete, rename, or reorder sheets even after opening it, and at the worksheet level, so individual cells and formulas on a specific tab can't be edited. Those three locks are independent. A file can have all three, just one, or any combination, and a script that only knows how to strip file-open encryption will still choke on a workbook whose structure or worksheets are separately locked.

That's the actual shape of the problem PDF4me's Office API solves for Excel. It handles Word and Excel automation over HTTPS, no Microsoft Office installation required on either end, and the security side of that API covers both directions: locking a workbook down with Secure Excel, and reversing it with the operation this article is about, Unlock Excel.

What the Unlock Excel endpoint actually does

The Unlock Excel REST endpoint is a single POST to https://api.pdf4me.com/office/ApiV2Excel/ExcelUnlock, with Content-Type: application/json and a Basic Authorization header carrying your API key.

The request body has three parts: a document object naming the file (a Name field, like data.xlsx), a top-level docContent string holding the whole workbook as Base64, and an unlockExcelAction object holding the one field that actually matters, password, plus an optional cultureName for locale-sensitive processing. Here's what that looks like end to end in Python:

import base64
import os
import requests

API_KEY = os.environ["PDF4ME_API_KEY"]
EXCEL_PASSWORD = os.environ["EXCEL_PASSWORD"]  # never hardcode this

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

payload = {
    "document": {
        "Name": "data.xlsx"
    },
    "docContent": doc_content,
    "unlockExcelAction": {
        "password": EXCEL_PASSWORD,
        "cultureName": "en-US"
    }
}

response = requests.post(
    "https://api.pdf4me.com/office/ApiV2Excel/ExcelUnlock",
    json=payload,
    headers={
        "Content-Type": "application/json",
        "Authorization": f"Basic {API_KEY}"
    }
)

result = response.json()

if not result.get("success", False):
    # Wrong password, or any other failure, lands here.
    # The file is returned untouched -- nothing partial happens.
    raise RuntimeError(result.get("errorMessage", "Unlock failed, no error message returned"))

unlocked_bytes = base64.b64decode(result["document"])
with open(result.get("fileName", "data_unlocked.xlsx"), "wb") as f:
    f.write(unlocked_bytes)

The response hands back the unprotected workbook as a Base64 document, a fileName, a success flag, and an errorMessage that gets populated specifically when the password is wrong. That last point is worth sitting with for a second: this is explicitly described as requiring the correct password, not cracking one. Feed it the wrong password and you get success: false and an untouched source file back, not a brute-force attempt and not a partially unlocked result. If you don't have the password, this endpoint has nothing for you. That's a deliberate boundary, not a missing feature.

One password field on REST, three on every integration platform

Here's the detail worth knowing before you build on more than one surface, because it isn't obvious from the REST page alone. The REST endpoint takes exactly one password field, which only works cleanly if a workbook's file-open password, workbook-structure password, and worksheet password are all the same value, or if the file only has one of those three locks to begin with.

The Power Automate action, the Make module, and the Zapier action all expose three separate, independently optional password fields instead of one: a file-open password, a workbook-structure password, and a worksheet password. All three apply a fallback chain: supply just the file-open password, and each platform tries it against the workbook and worksheet locks too before giving up. That's a meaningfully more capable interface than the bare REST call for the common real-world case of a file where IT set one password for everything, but it also means a workbook locked with genuinely different passwords at each layer needs the right one supplied at the right layer, on every platform except REST, which simply can't express that case at all with a single field.

PDF4me's n8n node handles the same three layers slightly differently again: it keeps separate File Encryption and Workbook Protection password fields, but worksheet-level unlocking is a plain on/off toggle, "Unlock Worksheets," off by default, rather than its own password input. Three platforms, three different takes on the same three-layer lock. Worth confirming against your actual file before you assume any one platform's shape, especially if you're porting automation logic from one of these to another.

What this operation won't do, and its direct inverse

Unlock Excel is strictly a removal operation. It doesn't inspect a file to tell you which of the three lock types are present before you call it, it doesn't recover a forgotten password, and it doesn't touch anything else about the workbook: formulas, formatting, sheet contents, and cell values all come back exactly as they went in. If what you actually need is to add protection in the first place, not remove it, that's the separate Secure Excel endpoint, which takes the inverse set of options: a password, a protectWorkbook flag, a protectWorksheets flag with a worksheetProtectionType of Contents, Objects, Scenarios, or All, and independent fallback passwords for each layer, mirroring the same three-lock model Unlock Excel removes. If your pipeline both receives protected files from one system and needs to re-protect its own output before handing it to another, you're looking at these two endpoints as a matched pair, not two unrelated features.

Which surface to build this on

None of the four integration platforms change what comes back, only how much control you get over which password goes where, so the choice mostly comes down to where the protected file already lands. If it arrives through a shared mailbox, a SharePoint library, or anywhere else already inside Microsoft 365, Power Automate keeps the whole unlock step inside that ecosystem without adding a second tool to maintain. Make's own documentation describes pulling the file in as binary content mapped from a prior step, such as a cloud-storage download, which fits a scenario where the protected workbook is already sitting in Drive, Dropbox, or an FTP drop before your scenario ever touches it. Zapier is the natural fit when the protected file is already the output of an earlier Zap step, a form upload or an inbox attachment parser, since the Unlock action just slots in as the next step with nothing extra to configure. n8n suits teams already running self-hosted or hybrid automation who want the unlock step living in the same workflow as everything else, including, in this one case, a plain on/off switch for the worksheet layer instead of a password field to fill in. REST is the fit when you want the logic living in your own codebase instead of a third-party automation platform, as in the Python example above.

A realistic version of this: the nightly encrypted export

Picture a payroll or banking integration that drops a password-protected .xlsx into a monitored folder every night, the password itself stored once in a secrets manager rather than typed by a human each time. A workflow built on Power Automate, Make, Zapier, n8n, or a scheduled script like the one above picks the file up on arrival, pulls the password from that secrets store, and runs the Unlock action before anything else touches the file. Every step after that, extracting specific rows, merging the sheet into a master report, reading values into a database, operates on a workbook that's never been manually opened by a person at all. The lock that used to mean "someone has to open this by hand first" becomes a single step at the front of the pipeline instead, and because a wrong password fails loudly with errorMessage populated rather than silently returning garbage, a bad credential in the secrets store gets caught the same night, not three reports downstream.

Where to go from here

If you're calling this directly, start with the REST API reference, and remember that it assumes one password covers every lock on the file. If you're building inside a no-code tool and need to handle a file-open password that differs from its workbook or worksheet passwords, the Power Automate, Make, Zapier, and n8n actions give you that flexibility, each with its own small variation on how the worksheet layer is addressed. And if your workflow needs to protect a file before Unlock Excel ever needs to touch it again, Secure Excel is the other half of that pair. Either way, what used to require a person with the password sitting at a keyboard becomes one HTTP call that either returns a clean, workable file or tells you plainly, and immediately, that the password was wrong.

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Password-Protect an Excel Workbook and Individual Worksheets via API

PDF4me — Sat, 10 Oct 2026 16:34:17 +0000

How to Password-Protect an Excel Workbook and Individual Worksheets via API

Somebody on your finance team sends out a pricing workbook. Three reviewers get a copy. One of them "just tidies up a formula," another deletes a sheet they didn't think anyone needed, and by the time the file comes back the totals don't match what went out. Nobody did anything malicious. They just had a spreadsheet, and a spreadsheet with no protection on it is an invitation to edit.

Excel actually gives you three separate locks for exactly this problem, and most developers only ever reach for one of them, if any. PDF4me's Office API exposes all three through a single call: Secure Document for Excel. Here's what each lock actually does, how to combine them, and where the real limits are.

Three locks, not one

It helps to stop thinking of "password-protecting Excel" as one feature. It's three, and they answer different questions.

File encryption answers "can this person even open the file?" Set a password here and the workbook won't open at all without it. This is the lock most people mean when they say "password protect."

Workbook structure protection answers "can someone rearrange the file itself?" This is the lock that stops a sheet from being added, deleted, renamed, hidden, or reordered. It has nothing to do with the data inside any one sheet. It protects the container, not the contents.

Worksheet content protection answers "can someone edit what's actually in the cells?" This is the familiar "unprotect sheet" dialog in Excel, except you're setting it programmatically, at scale, on files that were never touched by a human in Excel's own UI.

The reason the pricing workbook above got mangled is that whoever built the original file probably set none of these, or set file encryption and assumed that was the whole job. It wasn't. A password to open a file does nothing to stop someone who already has it open from renaming "Q3 Actuals" to "Q3 Actuals (old)" and starting fresh.

The one call that sets all three

PDF4me's ExcelSecure endpoint takes a document and a secureExcelAction object, and that object is where all three locks live together. Here's the exact request shape, verified against the live docs:

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

{
  "document": {
    "Name": "pricing-workbook.xlsx"
  },
  "docContent": "",
  "secureExcelAction": {
    "password": "openme123",
    "protectWorkbook": true,
    "protectWorkbookPassword": "structure456",
    "protectWorksheets": true,
    "worksheetProtectionPassword": "cells789",
    "worksheetProtectionType": "All",
    "worksheetNames": "Rates,Config",
    "worksheetIndexes": "",
    "cultureName": "en-US"
  }
}

Breaking down what each field in secureExcelAction actually does:

password: encrypts the file so it has to be entered just to open it. Leave the other two passwords blank and this one quietly becomes their fallback too, which matters more than it sounds like it should (see below).
protectWorkbook (a boolean, default false) plus protectWorkbookPassword: locks the structure. Someone with the workbook password can still open the file and read every sheet. They just can't touch the sheet list itself.
protectWorksheets (boolean, default false) plus worksheetProtectionPassword and worksheetProtectionType: locks cell-level editing. worksheetProtectionType takes Contents, Objects, Scenarios, or All, and defaults to All when you don't set it.
worksheetNames or worksheetIndexes: a comma-separated list that decides which sheets the worksheet lock actually applies to. Leave both empty and every sheet in the workbook gets protected. worksheetIndexes is 0-based, so the first sheet is index 0, not 1.
cultureName: a culture code (en-US and similar) for anything locale-sensitive in how the file gets processed.

The response comes back with the protected file, also Base64, plus a filename, a success flag, and an error message if something went wrong:

{
  "document": "",
  "fileName": "pricing-workbook.xlsx",
  "success": true,
  "errorMessage": null
}

One call, three layers, done. No separate round trip for each lock.

Why the password fallback matters more than it looks

Here's the detail that trips people up: if you set password but leave protectWorkbookPassword and worksheetProtectionPassword empty, PDF4me doesn't leave those two layers unprotected. It uses password for them too. That's a sensible default if your intent really is "just lock the whole thing with one password," but it means you can't assume an empty password field means "no protection at this level." Check whether password is set before you draw that conclusion, or you'll end up debugging a file that's actually locked in ways you didn't expect.

The flip side is just as useful in practice. Set all three passwords independently and you can hand one reviewer the file-open password and a completely different, separate password for editing the protected sheets. That covers a surprising amount of the "share this internally but keep it locked down" requests that show up in finance and ops workflows.

Protecting some sheets and not others

Most real workbooks mix sheets that should never change with sheets that are meant to be filled in. Think a locked "Rates" or "Config" tab sitting next to an open "Input" tab that a user fills out every week. That's exactly what worksheetNames and worksheetIndexes are for: name the sheets you want locked, by name or by position, and everything else in the file stays fully editable.

A practical pattern: protect every sheet except the one input tab by naming everything else explicitly, or flip it around and protect by index if your sheet names tend to change between files but the underlying layout doesn't.

The same call, four different front doors

If you're not calling the REST endpoint directly, the exact same settings show up in whichever automation tool you already run on.

Secure Excel in Power Automate exposes the same password, workbook, and worksheet fields as a flow action, with outputs for success and an errors array if something fails partway through.

Secure Excel for Make wires into a scenario the same way any other PDF4me module does: map a file name and document from an earlier step, set your passwords and protection toggles, and pass the resulting protected file on to an upload, email, or archive step.

Secure Excel for n8n accepts the input file as binary data, a Base64 string, or a public URL, which is handy if the workbook you're protecting is already sitting at a URL rather than attached to a node in your workflow.

Secure Excel for Zapier needs only the file itself as a required field, with everything else, including the password, optional, which makes it the fastest one to wire up for a simple one-password use case.

Whichever one you use, you're setting the same password / protectWorkbook / protectWorksheets triangle described above. Learning it once on the platform you already automate with carries over everywhere else.

Taking the lock back off

Protection that can never come off isn't protection, it's a dead end. When you need to reverse it, the same four-platform pattern exists for unlocking an Excel file: send the protected document and the password that was used to lock it, and the ExcelUnlock endpoint strips file encryption, workbook structure protection, and worksheet locks in a single pass.

It's worth being precise about what this does and doesn't do. It doesn't recover a password you've lost, and there's no way around that by design. It removes protection you already hold the key to, which is the only version of "unlock" you'd actually want an API offering in the first place.

What this protection is actually for

Worth saying plainly, because it's easy to assume otherwise: Excel's built-in protection, whether you set it by hand or through an API, is not the same thing as encrypting a file against someone who's determined to get in. PDF4me's own documentation for Secure Excel says it directly: standard Excel password protection deters casual access, it isn't strong cryptographic security.

Treat it as what it's actually good at: stopping a well-meaning colleague from reorganizing your sheet layout or typo-ing over a formula. Don't treat it as a substitute for proper document encryption if what you're actually worried about is a determined attacker.

That distinction decides what you reach for. Sending a budget template to twelve regional managers who shouldn't rename each other's tabs? Workbook and worksheet protection is exactly the right tool. Sending something that actually needs to resist a motivated outsider? That's a different problem entirely, and treating Excel's protection as if it solves it is the mistake worth avoiding.

Where this fits in a bigger pipeline

The real value here isn't locking one file by hand. It's that ExcelSecure becomes a normal, invisible step in a pipeline you already have running. Generate a report, merge in the latest rows, then secure it before it goes out the door, automatically, for every file, every time, with nobody needing to remember to click "Protect Sheet" before hitting send.

That's the real difference between a security setting and a security guarantee. One depends on a person remembering to do it correctly every single time. The other doesn't depend on anyone at all, which is the whole point of putting it behind an API in the first place.

If you can test the endpoint interactively before wiring it into a flow, do that first, so you know exactly what the response looks like before anything depends on it. Then build it in once, and every workbook that passes through your pipeline gets the same three locks, every time, without anyone having to think about it again.

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Pull Specific Rows or Ranges Out of an Excel Workbook as Structured Data

PDF4me — Fri, 09 Oct 2026 07:54:52 +0000

How to Pull Specific Rows or Ranges Out of an Excel Workbook as Structured Data

Most of the time, nobody wants your whole spreadsheet. A finance team doesn't need the formatting, the pivot tables, or the three dead sheets nobody deleted. They want rows 2 through 500 of the "Transactions" tab, as JSON, so their own system can do something with it. That gap between "here is an Excel file" and "here is the data I actually need" is where a surprising amount of integration code gets written badly, because reading a specific slice of a worksheet programmatically is less trivial than it looks.

Why reading a worksheet is harder than opening it

Open Excel, select a range, copy it. Done, for a human. For code, that same task means parsing a binary or XML-based file format, resolving which sheet you mean when a workbook has twelve of them, deciding whether row one is a header or data, and handling the fact that spreadsheets are full of things that break naive row-counting: hidden rows, fully blank rows left over from a deleted filter, and cells that are visually empty but not actually null. None of that is specific to PDF4me. It is just what "extract rows from Excel" means once you take it seriously.

PDF4me's Office API handles Word and Excel automation over HTTPS, no Microsoft Office installation required on either end. For Excel specifically, that includes adding rows, updating rows in place, merging workbooks, securing and unlocking files, and the operation this article is about: extracting rows.

What Extract Rows actually does

The Extract Rows REST endpoint is deliberately narrow. It is a read-only call. Send it a workbook, and it hands back a slice of that workbook as structured JSON. It does not modify, resave, or return a new file.

You POST to https://api.pdf4me.com/office/ApiV2Excel/ExcelExtractRows with a Content-Type: application/json header and an Authorization: Basic header. The body carries the workbook's Base64-encoded content plus an extractRowsToExcelAction object. Here's the minimal shape, straight from PDF4me's own docs:

{
  "document": { "Name": "data.xlsx" },
  "docContent": "UEsDBBQABgAIAAAA...",
  "extractRowsToExcelAction": {}
}

An empty extractRowsToExcelAction reads the default sheet in full. More usefully, it takes:

worksheetName or worksheetIndex, to target a specific sheet by name or by its zero-based position.
fromRow and toRow, the row range you want, also zero-based, where -1 means "through the last row that actually has data."
cultureName, which controls how dates and numbers get serialized. A workbook built in Germany and read with en-US culture can silently turn 1.234,56 into the wrong number, so this field matters more than it looks like it should.

Filled in, pulling a named sheet with the first 100 rows:

{
  "document": { "Name": "sales.xlsx" },
  "docContent": "UEsDBBQABgAIAAAA...",
  "extractRowsToExcelAction": {
    "worksheetName": "Q3",
    "fromRow": 0,
    "toRow": 99,
    "cultureName": "en-US"
  }
}

The response comes back as a rowData array, one object per row, plus a success flag you should check before you touch rowData at all, and an errorMessage that gets populated on failure, things like a missing worksheet or a corrupted file:

{
  "document": null,
  "fileName": null,
  "success": true,
  "errorMessage": null,
  "rowData": [
    { "ColumnA": "value1", "ColumnB": "value2" },
    { "ColumnA": "value3", "ColumnB": "value4" }
  ]
}

Row indexing being zero-based is a classic source of off-by-one bugs: "give me the first 100 rows" is fromRow: 0, toRow: 99, not 1 to 100.

Here's the same call in Python, using the request shape above:

import base64
import requests

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

payload = {
    "document": {"Name": "sales.xlsx"},
    "docContent": doc_content,
    "extractRowsToExcelAction": {
        "worksheetName": "Q3",
        "fromRow": 0,
        "toRow": 99,
        "cultureName": "en-US"
    }
}

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

result = response.json()
if result["success"]:
    rows = result["rowData"]
else:
    print(result["errorMessage"])

Headers, hidden rows, and the options the REST endpoint keeps minimal

The bare REST action is intentionally thin. The richer control over what counts as a "row" lives in PDF4me's integration-platform actions for this same operation, and they're worth knowing about even if you're calling the REST endpoint directly, because they show you what edge cases exist. The Power Automate action and the Make module both expose: treating the first row as column headers (or auto-naming columns Column1, Column2...), excluding hidden rows and hidden columns, excluding fully empty rows, and choosing whether to export every value as text or keep native types like numbers, booleans, and dates. That last option matters if you're piping the output straight into a system that's picky about type, a date that arrives as a string versus an ISO timestamp is a different bug report depending on which side of the integration you're debugging.

PDF4me's n8n action adds one more convenience worth calling out: it accepts the source file as binary data, a Base64 string, or a public URL, and writes its result, including a rowsExtracted count and the full settings it applied, into a binary slot your next node can read directly via $json.extractedData.rowData. That's a smaller detail, but it's the difference between wiring three nodes together cleanly and writing a Function node to reshape the output first.

The one inconsistency worth knowing about before you build on more than one platform

Here's something the docs don't call out directly, so it's worth being explicit: row and column numbering is not consistent across every PDF4me Extract Rows surface. The REST endpoint, the Power Automate action, the Make module, and the n8n node all use zero-based indexing, where -1 reaches the last row or column with data. PDF4me's Zapier action is the odd one out: its First Row, Last Row, First Column, and Last Column fields are explicitly documented as 1-based, "matching Excel," with -1 still meaning "through the last row or column with data." If you're moving the same automation logic from, say, Make to Zapier, that difference will cost you an off-by-one bug the first time you port a hardcoded range instead of re-deriving it. Treat that number as something to re-verify per platform, not something to copy-paste.

What this operation will not do for you

Extract Rows scopes by position: a starting row, an ending row, optionally a worksheet. None of the four platforms describe any way to filter by a cell's actual value, "give me only the rows where Status equals Overdue" is not something this endpoint does. If you need that, you pull the full range and filter in your own code or your automation platform's own filter step, treat Extract Rows as the data-fetching half of the job, not the querying half.

It's also worth separating this from two adjacent operations you'll bump into in the same product area. Extract Worksheets works one level up: instead of pulling specific rows from a sheet, it returns new workbooks containing only the whole tabs you select, by name or index. If what you actually want is "give me just the 'Q3' tab as its own file," that's Extract Worksheets, not Extract Rows. And if the workbook you're trying to read is password-protected, Extract Rows will simply fail against it. PDF4me's Unlock Document action removes file encryption and worksheet protection first, given the correct password. It can't recover a password you don't have, so this is a decryption step, not a bypass.

A realistic version of this: nightly report to API feed

Picture a finance system that drops a fresh .xlsx export into SharePoint or Google Drive every night at 2 a.m., a transaction log with a header row and anywhere from 40 to 4,000 data rows depending on the day. Manually opening that file to copy data into another system doesn't scale past about day three. Wired through Power Automate, Make, or n8n, the shape of the automation looks the same regardless of which platform you pick: a trigger fires when the new file lands, the Extract Rows action reads it with headers enabled and hidden rows excluded, and the resulting RowData array gets looped, with each row posted to an internal REST API or queued into a database insert. The entire "parse last night's spreadsheet" problem collapses into one action step, instead of a scheduled script somebody has to maintain and restart when it silently stops working.

Where to go from here

If you're calling this directly, start with the REST API reference and get the zero-based range math right before you add platform-specific options on top. If you're building this inside a no-code tool, the Power Automate, Make, Zapier, and n8n actions each wrap the same underlying call, with the row-numbering caveat above being the one detail that doesn't travel automatically between them. Either way, a worksheet that used to require someone opening Excel by hand becomes one HTTP call that returns exactly the rows you asked for and nothing else.

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Append Data to an Excel Worksheet via API Without Opening Excel

PDF4me — Thu, 08 Oct 2026 19:26:40 +0000

How to Append Data to an Excel Worksheet via API Without Opening Excel

Every business has at least one spreadsheet that quietly runs half of it. A "DailySales" workbook that finance refreshes every morning. A response log that catches every form submission before anyone builds a real database for it. A CRM export that gets emailed around every Monday because nobody trusts the dashboard. These workbooks work, right up until someone has to update them without actually opening Excel: a scheduled job, a webhook, a background service that needs to write five new rows into a worksheet that a human is going to open two hours later.

That's a smaller problem than it sounds, and also a bigger one. Smaller, because appending rows to an Excel file is conceptually trivial: take some data, put it below the last row. Bigger, because the moment you actually write that code yourself, you run into questions a one-line "append a row" ask never mentions. Does the new data need to match an existing header row, or go into specific cells? What happens if the sheet is a real Excel Table, with named columns and formatting that breaks if you write past its boundary? Does a date string need to become an actual Excel date, or does it arrive as plain text? And what happens when the thing that needs those three new rows is a serverless function that has no business knowing what openpyxl or ClosedXML is?

PDF4me's Excel Add Rows API answers this with a single HTTP call that takes a workbook and a JSON payload and hands back the updated workbook. No Excel installation, no COM interop, no spreadsheet library to patch every time Microsoft changes something. It's worth walking through exactly how it works, because the two insertion modes it supports, table mode and coordinate mode, are where most hand-rolled "just append a row" scripts eventually get it wrong.

What the Add Rows Endpoint Actually Does

The REST endpoint is POST office/ApiV2Excel/ExcelAddRows. Headers: Content-Type: application/json and Authorization: Basic YOUR_BASE64_ENCODED_API_KEY (get a key at the PDF4me dashboard). You send a document object holding the workbook's filename, a docContent field with the workbook's Base64-encoded bytes, and an addRowsToExcelAction object that carries the actual instructions. The one field every call needs inside that action object is jsonInput: a JSON array of objects (or a single object) given as a string, where each object becomes one new row.

That last detail trips people up the first time. jsonInput isn't a nested JSON array in your request body; it's a string containing JSON, which means the quotes inside it have to be escaped.

Sample request:

{
  "document": { "Name": "data.xlsx" },
  "docContent": "UEsDBBQABgAIAAAA...",
  "addRowsToExcelAction": {
    "jsonInput": "[{\"Name\":\"John\",\"Age\":30}]"
  }
}

The API returns the updated Excel document as a Base64-encoded string in JSON, alongside fileName, success, and errorMessage fields.

Table Mode vs. Coordinate Mode

This is the part a DIY script usually gets wrong, because it's invisible until it isn't. The API supports two different ways of deciding where new rows land, and mixing their parameters in the same call returns an error rather than a guess.

Table mode is for worksheets where the data already lives inside a real Excel Table object. Set tableName to that table's name, and the API matches each JSON object's property names to the table's column headers, then inserts the row at the position given by excelRowNumber (1-based). Matching happens by header name, not column order, so the order of keys in your JSON doesn't need to match the order of columns in the sheet.

Coordinate mode is for a plain range of cells with no formal table object. Leave tableName empty, and set insertFromRow and insertFromColumn (both 1-based) to the starting cell. Values are written in the order the JSON properties appear, with no header matching at all, which also means a coordinate-mode write can silently overwrite existing cells if the start position is wrong. There's no undo button on an API call, so get the starting cell right first.

A few more fields round out the behavior: convertNumericAndDate (default true) turns a string like "2026-10-08" into a real Excel date using dateFormat (yyyy-MM-dd default) and numericFormat (N2 default), with cultureName (en-US default) controlling how ambiguous dates and decimals get parsed. ignoreNullValues skips writing a cell at all when a property's value is null. ignoreAttributeTitles makes table-mode header matching case-insensitive, which is the difference between a silent miss and a working match when your source sends CustomerName and your table header is customername. worksheetName defaults to Sheet1 if omitted.

Why This Beats Writing It Yourself

A hand-rolled version in Python or C# isn't hard to start. It's hard to finish. You end up handling the table-vs-coordinate branching yourself, writing your own type-conversion logic for dates and numbers across locales, and testing against Excel quirks (shared formulas, conditional formatting that doesn't extend, a table that refuses to grow past its defined bounds) that only show up once real users send real data. A REST call with a JSON body and a Base64-encoded file is something almost any environment, including a serverless function with no business installing a spreadsheet library, can make without new dependencies.

Using It Without Writing Code: Power Automate, Zapier, n8n, and Make

The same action is available as a native step in the no-code automation platforms PDF4me integrates with.

In Power Automate, the Excel - Add Rows action takes the same fields as the REST call and returns the updated workbook plus Success, ErrorMessage, and Errors a flow can branch on. Documented scenarios: a scheduled SQL query feeding a "DailySales" table every morning, a Microsoft Forms submission landing in the next open row of a response log saved back to SharePoint, and a weekly CRM export populated into an "Opportunities" table with case-insensitive header matching.

Zapier's Add Rows to Excel action follows the same shape, with a JSON array from an earlier Zap step mapped into the action's JSON Input field. Its own documented example, a daily sales export written into a templated "DailySales" table on Google Drive with date/currency formatting applied before upload and email, claims it saves roughly two hours of manual entry a day. Worth treating as Zapier's own stated estimate, not an independently verified number.

n8n's PDF4me Excel: Add Rows node surfaces a detail the others don't: its output includes rowsAdded, a count you can compare against your input array's length with an IF node to verify every row actually landed, rather than assuming success because the call didn't error. The same action is also available through Make, PDF4me's fourth supported no-code platform, via its own app listing on Make's marketplace.

Where This Fits and Where It Doesn't

This API appends rows to an existing workbook; it doesn't build one from scratch. For generating a brand-new Excel file from JSON data, see Convert JSON to Excel. For removing rows afterward, there's a matching Delete Rows endpoint built the same way.

The honest limit: this is a synchronous, stateless call. It doesn't watch a folder, doesn't know your data source, and doesn't decide when to run; something else (a cron job, a webhook, a Power Automate trigger) still has to supply the workbook, the JSON, and the timing. What it removes is the part that used to require either a human with Excel open or a maintained library of spreadsheet-manipulation code.

Sample code and SDKs: pdf4me-api-samples on GitHub

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Merge Multiple Excel Workbooks Into One File via API

PDF4me — Thu, 08 Oct 2026 04:47:02 +0000

How to Merge Multiple Excel Workbooks Into One File via API

Every month-end close has the same ritual. Five regional managers each send their own spreadsheet. Someone, usually the least senior person on the finance team, opens all five, copies each tab into one master workbook, renames the sheets so they don't collide, and prays nobody fat-fingers a cell reference along the way. It's not hard work. It's just work that a computer should be doing, and isn't, because "just write a script to merge Excel files" turns out to hide more edge cases than it sounds like it does.

What happens when two source files both have a sheet named "Summary"? What happens when one file has three worksheets and another has twelve, and you only want sheet two from each? These aren't hypothetical. They're the reason a one-line "combine these files" request usually turns into a half-day of writing and testing openpyxl or EPPlus code, then maintaining it every time a source format changes.

PDF4me's Excel Merge Files API handles this as a single HTTP call. Here's exactly how it works, including the request/response shape.

The REST Endpoint

POST office/ApiV2Excel/ExcelMergeFiles
Content-Type: application/json
Authorization: Basic YOUR_BASE64_ENCODED_API_KEY

The request body, exactly as documented on the Merge Files Excel API page:

{
  "mergeFilesToExcelAction": {
    "documents": [
      { "filename": "file1.xlsx", "fileContent": "UEsDBBQABgAIAAAA..." },
      { "filename": "file2.xlsx", "fileContent": "UEsDBBQABgAIAAAA..." }
    ],
    "outputFileName": "merged.xlsx"
  }
}

A few things worth knowing before you copy this into your own code:

fileContent is the Base64-encoded bytes of each source workbook, not a file path or URL.
The API merges documents in array order, so East/West/Central/South ordering in a regional report comes from how you build this array, not from anything alphabetical.
The docs page notes the casing is flexible: documents/Documents, filename/Filename, fileContent/FileContent all work.
outputFileName is optional (defaults to merged.xlsx), and there's also an optional cultureName field (e.g. en-US) for locale-sensitive processing, not shown above since the docs example omits it too.

The response comes back as JSON with document (the merged workbook, Base64-encoded), fileName, success, and errorMessage. The docs page doesn't publish a full sample response body, so don't assume field nesting beyond those four names until you've seen a live response from your own account.

Decoding and Saving the Result (Python)

import requests
import base64
import json

api_key = "YOUR_BASE64_ENCODED_API_KEY"
url = "https://api.pdf4me.com/api/v2/office/ApiV2Excel/ExcelMergeFiles"

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

payload = {
    "mergeFilesToExcelAction": {
        "documents": [
            {"filename": "east.xlsx", "fileContent": encode_file("east.xlsx")},
            {"filename": "west.xlsx", "fileContent": encode_file("west.xlsx")},
        ],
        "outputFileName": "merged.xlsx"
    }
}

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

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

if result.get("success"):
    with open("merged.xlsx", "wb") as f:
        f.write(base64.b64decode(result["document"]))
    print(f"Saved {result['fileName']}")
else:
    print(f"Merge failed: {result.get('errorMessage')}")

A note on verification: this sample uses only the request/response field names confirmed live on the docs page above. I wasn't able to cross-check against the official pdf4me-api-samples GitHub repo this session (it blocked automated fetches), so if you hit a field name mismatch in practice, the live API response from your own account is the authority, not this snippet.

Where This Gets More Capable: The No-Code Integrations

If you're not writing a custom integration, the no-code platform versions of this action expose more control than the bare REST contract above, specifically around worksheet selection and output format.

Power Automate's PDF4me Merge Excel Files action takes a list of documents where each entry can include an optional list of worksheets to merge. Leave it empty and every sheet comes along; populate it and you pull only the sheets you want, useful when someone's quarterly report has a "scratch calculations" tab you don't want shipped to the board. It also lets you pick the output format: XLSX by default, or XLS, PDF, or CSV (CSV exports only the first worksheet).

Make's PDF4me Excel to Merge Files module mirrors this with a Files array where each item carries an optional Sort Position (lower numbers merge first) and an optional Worksheets To Merge list, plus the same four output formats. Zapier's PDF4me Merge Files action automatically renames duplicate worksheet names across source files, so two files that both have a "Data" tab don't silently overwrite each other. n8n's Merge multiple Excel files node takes the same documents-plus-worksheets-plus-format shape, with the result landing as a native n8n binary object (correct Excel MIME type) so it flows straight into the next node.

Worth flagging: the REST API's own documentation doesn't describe an explicit output-format parameter the way all four integration platforms do. If you're calling REST directly, verify against your account's live response whether format selection applies there too, rather than assuming XLSX-only.

Sort Order and Worksheet Filtering, in Practice

The pattern is consistent across every platform: build a list of source files, give each an optional sort position (or rely on array order where that's all that's supported), and optionally name which worksheets you want. That's the whole decision tree, and it maps directly onto the actual common case: consolidating monthly reports where some files carry extra tabs you don't want, in an order that matters to whoever reads the output.

The duplicate-worksheet-name handling matters more than it sounds. Two regional reports both naming their summary tab "Summary" is extremely normal. A hand-rolled merge script that doesn't think about this will silently let the second "Summary" overwrite the first, and nobody notices until finance asks why the East region's numbers disappeared.

Where This Fits in a Bigger Pipeline

Merging rarely happens in isolation. It's usually one step: pull five regional exports from a shared drive, merge them, maybe convert the result to PDF for archival, then email it out. Because this is one HTTP call (or one no-code module) rather than a library you install and maintain, it slots into a Power Automate flow triggered by a new SharePoint file, a Make scenario watching a Drive folder, a Zapier zap off a form submission, or an n8n workflow chained with other document steps. PDF4me's broader Word and Excel API covers the surrounding operations too: splitting workbooks back apart, comparing versions, watermarking, password protection, and PDF-to-Office conversions.

The Honest Limits

This endpoint merges workbooks and lets you choose worksheets and order. It does not reconcile conflicting cell formulas across files, does not deduplicate rows that mean the same thing but are phrased differently, and won't catch a schema mismatch where one region's spreadsheet has an extra column the others don't. Those are data-modeling problems upstream of the merge, not inside it. What it reliably removes is the tedious part: opening N files, copying N sets of tabs, hoping you didn't drop a sheet or get the order wrong.

If you're maintaining an in-house script for this today, a quick gut check: how long would it take to add "exclude the scratch tab" as a new requirement in your existing code, versus adding one worksheetsToMerge field to a request you're already sending?

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Extract Line Items, Totals, and Customer Info from Purchase and Sales Orders via API

PDF4me — Wed, 07 Oct 2026 18:46:14 +0000

Every procurement, fulfillment, or ERP-adjacent team ends up building the same throwaway tool eventually: something that opens a purchase order PDF, finds the line items, finds the total, and matches it against whatever system of record actually runs the business. Then a new supplier sends a PO in a different layout, the regex breaks, and someone spends an afternoon patching a parser nobody wanted to own in the first place.

Purchase orders and sales orders are two sides of the same transaction (one side issues it, the other side fulfills it) but they get treated as a document-handling problem twice, once per direction, because most parsing tools make you describe the layout before they'll read it. That's the part worth fixing, not the OCR.

Why one parser has to cover both documents

A purchase order and a sales order carry almost the same information: an order number, a date, who it's for, what's being ordered, how many, at what price, and what the total comes to. The difference is which side of the transaction wrote it. A buyer's procurement system generates POs; a seller's order-entry system generates SOs. Downstream, a reconciliation or fulfillment system usually needs to read both, because one company's outgoing PO is often another company's incoming SO in the same workflow.

That shared shape is exactly why a schema-driven parser works here in a way that template matching doesn't. A capture-area tool anchors to pixel coordinates, so a vendor that moves their logo six millimeters to the left breaks the template. A regex-based tool anchors to text patterns, so "Total:" vs "Total Due:" vs "Amount Due" each needs its own rule. Neither approach generalizes across a supplier list you don't control the formatting of.

What the AI Order Parser actually returns

PDF4me's AI Order Parser skips capture areas and regex entirely: you send it a PDF or image, it returns a fixed JSON shape, and per PDF4me's own Make.com integration documentation that shape is identical whether the source document is a purchase order or a sales order ("works without template setup," "the two document types return the same schema").

The documented output fields:

orderNumber (string): order or reference number, whatever format the document uses (PO-2024-001, SO-78423, etc.)
orderDate (string): normalized to ISO 8601 (YYYY-MM-DD)
customerName (string): the customer or vendor name on the document
lineItems (array): each row carries description, quantity, unitPrice, total
subTotal (number): amount before taxes, shipping, discounts
total (number): final amount including all charges
currency (string): ISO 4217 code (USD, EUR, INR, ...)
shippingAddress (string): shipping or delivery address
jobId (string): PDF4me's own job ID, for audit/support
success (boolean) / message (string): completion status

A realistic response:

{
  "success": true,
  "jobId": "a1b2c3d4-e5f6-4789-9abc-def012345678",
  "orderNumber": "PO-2024-00187",
  "orderDate": "2026-09-14",
  "customerName": "Meridian Fabrication Ltd.",
  "currency": "USD",
  "lineItems": [
    { "description": "M8 Stainless Hex Bolt, 40mm", "quantity": 500, "unitPrice": 0.42, "total": 210.00 },
    { "description": "M8 Stainless Washer", "quantity": 500, "unitPrice": 0.06, "total": 30.00 }
  ],
  "subTotal": 240.00,
  "total": 259.20,
  "shippingAddress": "4410 Industrial Pkwy, Unit 12, Dayton, OH 45417",
  "message": "Extraction completed."
}

That's enough to populate an ERP line, run a reconciliation threshold check, or trigger a fulfillment workflow without a human opening the PDF first.

A documentation gap worth being upfront about: there's no published REST-only walkthrough for this specific action on docs.pdf4me.com (confirmed 404, not assumed), and the official pdf4me-api-samples repo on GitHub doesn't have an Order Parser folder either, unlike several of the other AI parsers in this cluster. Make.com is currently the one platform with a dedicated, field-by-field written guide for this action. If you're calling this over the raw REST API, the schema above (verified against Make's docs) is what to expect back, but test against your own documents before you build a strict validator around it.

A second gap, this one a discrepancy rather than a missing page: PDF4me's Power Automate connector (listed on Microsoft's own connector reference as AI - Order Parser / operation ID ProcessOrderAi) documents a noticeably different output shape for what is nominally the same action, built around invoiceToName/deliverToName pairs, a products array, and a few fields that read like leftovers from one specific customer's template rather than a general-purpose schema. That's either a different model version, a stale page on Microsoft's side, or a connector-specific response wrapper, and there's no way to tell which from the outside. If you're building on Power Automate, run a live test order through the action and check the actual field names it returns before wiring a Flow around either schema.

Where this fits in a no-code or custom stack

Make: the one platform with a dedicated, written walkthrough for the AI-Process Order module, including the field table above. Map Order Name and the document binary, run an Iterator over lineItems if you need one ERP row per line item, done.
Power Automate: the same capability exists as a native connector action (ProcessOrderAi), available across Power Automate, Power Apps, and Copilot Studio (Premium) per Microsoft's own connector listing, with a 100-calls-per-60-seconds throttle per connection. Verify the live output fields yourself, per the discrepancy noted above.
REST API: PDF4me's broader AI parser family is reachable directly for teams building their own backend instead of a no-code flow, following the same API key and connection pattern as PDF4me's other endpoints.
When the fixed schema isn't enough: orders carrying fields the standard parser doesn't name (a custom SKU format, a project code, a buyer-specific approval field) are a better fit for PDF4me's Universal Document Parser, which lets you specify the exact fields to extract, or the Document Parser / custom analyzer path, which lets you define a reusable extraction profile in the PDF4me dashboard. Reach for either one before writing a post-processing script to bolt extra fields onto the Order Parser's output.

The actual use case this solves

Picture a small distributor that takes purchase orders by email, as PDFs, from forty different retail accounts, each using whatever order-entry system that retailer happens to run. Nobody on the distributor's side wants to build forty templates. Dropping every incoming PO through the Order Parser, regardless of sender, normalizes them all into the same orderNumber / lineItems / total shape before anything touches the warehouse management system. The matching logic downstream (does this line item exist in inventory, does the total reconcile, does this need a human to look at it) only has to be written once, against one schema, instead of once per retailer.

The same logic runs in reverse for a seller reconciling their own outgoing sales order confirmations against what a buyer's procurement system actually received, which is the other half of why one shared schema across both document types is worth more than it sounds.

What this doesn't solve

This parser reads documents, it doesn't validate business logic. It won't tell you whether a total is actually correct given the lineItems listed (that's a reconciliation check you still write), and it won't catch a line item that's missing entirely if the source document itself never listed it. Treat the extraction as trustworthy input to your own validation step, not a replacement for one.

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Parse W-2, 1099, and 1040 Tax Forms Automatically with One API

PDF4me — Wed, 07 Oct 2026 06:23:58 +0000

Tax season turns into a document-matching exercise for a lot of software teams that have nothing to do with accounting. A lending platform verifying income needs the wages box off a W-2. A background-check or underwriting tool needs the adjusted gross income line off a 1040. An HR onboarding flow needs the withholding figures off a W-4. None of these teams want to become tax-form experts. They just want the handful of numbers that matter, pulled out of a PDF someone uploaded, without building a different parser for every form a tax season throws at them.

That is a harder problem than it sounds, and it is worth being specific about why before looking at the API that solves it.

Why One Tax Form Parser Has to Behave Like Thirteen

A W-2 and a 1040 do not share a layout, a vocabulary, or even a purpose. One is an employer's wage statement. The other is a full individual income tax return with dozens of line items. A 1098 reports mortgage interest. A 1095-A reports health insurance coverage months. Build a parser tuned to a W-2's box numbers and it has nothing useful to say about a 1040. Build a generic OCR pipeline instead and you get back a wall of unlabeled text, with a human, or another piece of custom code, left to figure out which number is adjusted gross income and which one is a state tax withholding on a completely different form.

PDF4me's AI Tax Document Parser is built around that specific problem: one API surface that identifies which of thirteen named form types it is looking at, then returns the field set that actually applies to that form. Feed it a W-2 and it returns W-2 fields. Feed it a 1040-SR and it returns 1040 fields, not an empty W-2 template with nothing filled in.

The Response Envelope, Field for Field

Every response, regardless of which form came in, carries the same core envelope:

{
  "formType": "W2",
  "taxYear": "2023",
  "fields": {
    "employerName": "...",
    "employerEin": "...",
    "wagesTips": "...",
    "socialSecurityWages": "...",
    "medicareWages": "...",
    "stateWages": "...",
    "stateIncomeTax": "..."
  },
  "warnings": [],
  "fallbackUsed": false,
  "rawOcrText": "...",
  "jobId": "...",
  "success": true,
  "message": "..."
}

That envelope shape is confirmed identical across the Power Automate, n8n, and Zapier documentation pages for this parser. None of the three publishes a full sample response with real values, so the field names above are drawn directly from each page's documented output schema, not copied from an example payload that does not exist yet on any of them.

What changes between calls is what lands inside fields. The parser recognizes thirteen named form types across six categories: wage statements (W2), information returns (1099 and 1099-SSA), individual returns (1040, 1040-SR, 1040-NR), interest and education statements (1098, 1098-E, 1098-T), health coverage forms (1095A, 1095C), and withholding declarations (W-4), plus a catch-all UnifiedTaxUS classification. A 1040 response fills fields with filing status, taxpayer name, taxpayer SSN, address, wages, total income, adjusted gross income, taxable income, total tax, federal income tax withheld, and refund amount instead of the W-2 fields shown above. A 1098 response fills it with mortgage interest, student loan interest received, and qualified tuition and related expenses. Across all thirteen form types combined, the documented field vocabulary runs past sixty distinct values, but no single response returns all sixty at once, only the subset that belongs to whatever form type formType just identified.

Treat formType as more than metadata. It is the signal that tells your downstream code which keys to even expect in fields before it tries to read them. A pipeline that reads fields.wages off every response without checking formType first will quietly break the moment a 1098 shows up where a W-2 was expected, since fields.wages simply will not exist on that response.

One documentation discrepancy worth flagging directly: PDF4me's own n8n page groups the same thirteen form codes into what it calls twelve document categories (1099 and 1099-SSA counted together under one category there), while the Power Automate page counts thirteen form types directly. The supported forms are identical either way. This is a grouping difference between two docs pages, not a coverage gap, so do not be surprised seeing both numbers in the wild.

Build Error Handling Around warnings and fallbackUsed, Not Just the Dollar Fields

Three fields in that envelope matter more than the numbers they sit next to. warnings flags extractions the parser itself is not confident about. fallbackUsed tells you whether it had to fall back to a secondary extraction path to get an answer at all. rawOcrText hands a human reviewer the raw text to check against when something looks off. A tax document feeding a loan decision or a background check is exactly the kind of input where a quietly wrong number is worse than a clearly flagged uncertain one. A pipeline that reads the dollar fields and discards warnings is throwing away the one signal built specifically to catch a bad extraction before it reaches a human decision downstream.

There is also an optional customFieldKeys parameter for pulling additional fields beyond the standard set for a given form type, documented on the Power Automate page as an Advanced parameter alongside TaxModel, for workflows that need one more data point than the built-in schema covers.

No Dedicated REST Page, Same Pattern as This Parser's Siblings

Anyone looking for a plain REST endpoint outside the four no-code platforms will not find one. There is no dedicated pdf4me-api page for this specific parser; https://docs.pdf4me.com/pdf4me-api/pdf4me-ai/ai-tax-document-parser/ returns a 404, confirmed directly while researching this piece, the same finding this cluster has run into for the AI Mortgage Document Parser and the AI Pay Stub/Payslip Parser before it.

What the REST layer gives you instead is the generic Analyzer mechanism that every named parser in PDF4me's AI lineup sits on top of. You define a fieldName, fieldType, and fieldDescription for each value you want back, save it under a stable AnalyzerId in the dashboard, and that identifier is what every subsequent API call references. The documented request shape, confirmed live against that page, is:

{
  "docName": "w2_form.pdf",
  "docContent": "BASE64_ENCODED_PDF_CONTENT",
  "AnalyzerId": "tax_document_parser",
  "async": false
}

sent as a POST to the base API confirmed on PDF4me's connect-to-pdf4meapi page: https://api.pdf4me.com, at the /api/v2/ path. The named Tax Document Parser covered above is the faster path when the documents really are standard W-2s, 1099s, and 1040s, since the thirteen-form schema is already built for you. The Analyzer route is what you reach for when a tax-adjacent document falls outside those thirteen types, because fieldDescription lets you point the model at exactly the value you want instead of picking from a fixed list.

One more honest gap worth naming: the official pdf4me-api-samples repository, which has working code for most of PDF4me's REST features in C#, Java, Python, JavaScript, and Apex, currently has no folder for tax document parsing specifically, since this AI parser family is newer than that repo's existing coverage. The Analyzer request shape above is confirmed from the docs page itself, not from a tested sample script, so verify the exact response shape against your own test call before shipping it.

Three Platforms Fully Documented, One Still a Stub

In Power Automate, the action drops into a flow the way any other step does: a document lands by email or form upload, the action returns the structured fields, and the flow routes them wherever onboarding or underwriting logic lives next. In n8n, the node covers the self-hosted or more code-adjacent case, sitting inside a larger automation that might also write to a database. In Zapier, the same extraction becomes a step that can follow a Gmail attachment trigger or a Drive upload.

Make is worth a direct note rather than a smoothed-over one. Its own integration page is live, but it is currently a stub, labeled on the page itself as adapted from the n8n equivalent with full documentation still pending. The module exists and the supported form list matches the other three platforms, but anyone building against it today should verify the exact field output in a real test call rather than relying on the docs page for a complete field table the way they could for Power Automate, n8n, or Zapier.

A Concrete Case: Income Verification Across Mismatched Form Types

Picture a lending team that collects income documentation from applicants who do not all submit the same kind of paperwork. A salaried applicant uploads a W-2. A self-employed applicant uploads a 1099. Someone refinancing uploads a 1098 showing mortgage interest paid. Today, a human opens each one, works out which document type it even is, and manually keys the relevant figures into the loan file.

Wiring this parser into that intake point changes the shape of the work rather than just speeding up the typing. Every upload gets the same call. formType tells the system which document just arrived without a human needing to eyeball it first, and fields already matches that form type, whether that means wages and withholding from a W-2 or nonemployee compensation from a 1099. warnings routes the handful of genuinely uncertain extractions to a reviewer instead of routing every single document to one. The reviewer's job shifts from re-typing numbers and sorting document types to judging the small number of edge cases the parser itself flagged. The same pattern applies past lending: a background-check platform reconciling a 1040's adjusted gross income against a stated salary, or an HR team processing a new hire's W-4 withholding elections.

Where to Start

If the documents in question are genuinely one of the thirteen supported form types, the named parser is the faster path. No schema to design, just a document in and the right field set out, with formType telling you which set you got. Test it against real forms from an actual tax season rather than a single clean sample, since form layouts shift year to year. Build your error handling around warnings and fallbackUsed from the start rather than retrofitting it after a bad extraction reaches a decision it should not have. If a document falls outside the thirteen supported types, or you are on Make and need more certainty than today's stub page can offer, the Analyzer-based route above is the fallback that does not require waiting on anyone else's documentation to catch up.

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Automate Payroll Data Entry: Extracting Gross Pay, Deductions, and YTD Totals from Pay Stubs via API

PDF4me — Wed, 07 Oct 2026 04:27:23 +0000

How to Automate Payroll Data Entry: Extracting Gross Pay, Deductions, and YTD Totals from Pay Stubs via API

Ask anyone who has processed payroll by hand what breaks first, and they will not say the math. They will say the typing. A pay stub looks like one document, but it is actually a dozen small facts packed onto one page: gross pay, net pay, four or five separate tax withholdings, overtime hours at a different rate than regular hours, a 401(k) deduction, a year-to-date column that has to match last month's year-to-date column plus this period's numbers. Copy one of those wrong into a loan application, a background-check report, or an HR system, and the error does not announce itself. It just sits there until someone's income verification comes back inconsistent with their bank statement.

That is the specific failure a document parser is built to prevent, and it is worth being precise about what the API actually returns before wiring anything up.

Why a Pay Stub Is Harder to Automate Than It Looks

Every payroll system lays its stub out differently. ADP, Gusto, Paychex, and a thousand smaller in-house systems each put gross pay in a different spot on the page, label overtime differently, and format a pay period as a date range, a single end date, or a cycle number. A regex rule tuned to one format breaks the moment a new employer's stub shows up. A generic OCR pass reads the characters correctly and then hands back forty lines of unlabeled text, leaving a human, or a second piece of custom code, to figure out which number is the employer's EIN and which one is a garnishment.

PDF4me's AI Pay Stub/Payslip Parser exists to skip that step. It reads the document, whatever its layout, and returns the same structured fields every time: grossPay is always grossPay, whether the source stub came from a national payroll provider or a spreadsheet someone printed to PDF.

The Exact Fields That Come Back

Here is the field list as documented on the Power Automate integration page, which gives the most complete output table of the four platforms:

grossPay              netPay                payPeriod
payDateStr            federalIncomeTax      stateIncomeTax
socialSecurityTax     medicareTax           localCityTax
employeeName          employeeIdSsn         employeeAddress
jobTitle              companyName           employerAddress
employerEin           regularHours          overtimeHours
regularRate           overtimeRate          totalHours
healthInsurance       retirement401k        otherBenefits
garnishments          ytdGrossPay           ytdNetPay
ytdFederalTax         ytdStateTax           checkNumber
directDepositInfo     vacationSickTime      commissionBonus
warnings              fallbackUsed          rawOcrText
jobId                 jobIdExt              success
message

That is 41 distinct keys in that page's own output table (40 data fields plus a wrapping fields object). Do not treat that as a universal total, though. The n8n node's own payStubData object documents 40 named fields, the Make module's FAQ cites 19 in its primary output table with more in extended output, and Zapier's page gives no total at all. The field sets overlap heavily rather than genuinely differing, so write your integration against the fields you actually pull back in a real test call, not against whichever integration page's count you read first.

warnings, fallbackUsed, and rawOcrText are worth building around deliberately rather than ignoring: warnings flags low-confidence extractions, fallbackUsed tells you whether the parser fell back to a secondary extraction path, and rawOcrText gives a human reviewer the raw text to check against when something looks off. A pipeline that reads success and the dollar fields but throws away warnings is discarding the one signal built specifically to catch a bad extraction before it reaches a loan file or an HR record.

No Dedicated REST Page, and What That Means for a Custom Integration

Worth noting for anyone looking for a plain REST endpoint outside the four no-code platforms: there is no dedicated pdf4me-api page for this specific parser (confirmed as a 404 on the expected path while researching this piece, same finding as this cluster's earlier AI Mortgage Document Parser article). What the REST layer gives you instead, per the general-guidelines AI Document Parser (Parse) page, is the generic Analyzer mechanism that every named parser in PDF4me's AI lineup sits on top of. You create an Analyzer in the dashboard (a user-defined identifier, e.g. pay_stub_parser), specify a fieldName, fieldType (string, number, date, or table), and a fieldDescription per value you want back, and that stable AnalyzerId is what every subsequent API call references. The request body shape, as documented on that page, is:

{
  "docName": "pay_stub.pdf",
  "docContent": "BASE64_ENCODED_PDF_CONTENT",
  "AnalyzerId": "pay_stub_parser",
  "async": false
}

against the base API documented at general-guidelines/connect-to-pdf4meapi: https://api.pdf4me.com, over POST. The named, no-code-platform parser (the one this article is mostly about) is the faster path when the documents really are standard pay stubs and the fixed field list above already covers what you need. The Analyzer route is what you reach for instead when a field you need is not on that list, or the document is payroll-adjacent but not a standard pay stub, since fieldDescription lets you point the model at exactly the value you want rather than picking from a preset schema.

The Same Extraction, Four Front Doors

The underlying extraction is the same regardless of how you trigger it, but the way you wire it into a workflow depends on where that workflow already lives.

In Power Automate, the connector slots into a flow the way any other action does: drop in a pay stub from email, SharePoint, or a form upload, get structured payroll fields back, and route them into whatever system handles onboarding or payroll review next. In Make, the module does the same job inside a scenario, a natural fit if the pay stub is already arriving through a Make-connected inbox, cloud drive, or form tool. n8n covers the self-hosted or more code-adjacent case, where the node sits inside a larger automation that might also touch a database or an internal API. And in Zapier, the same extraction becomes a step that can follow a Gmail attachment trigger or a Google Drive upload, often the fastest way for a smaller HR or lending team to get this running without writing any code at all.

Pick the surface that matches where the pay stubs already land, not the other way around.

A Concrete Case: Income Verification Without Re-Typing Anything

Picture a small lending team that verifies income manually today. An applicant uploads two or three recent pay stubs through a web form or emails them in. Someone opens each PDF, reads off gross pay and net pay, checks ytdGrossPay against roughly three times the pay period figure to catch an obviously stale or doctored document, and keys everything into the loan file by hand. Multiply that by dozens of applications a week and the bottleneck is never the underwriting logic. It is the data entry in front of it.

Wiring the parser into that same intake point changes the shape of the work rather than just speeding it up. A form submission or an inbox rule triggers the extraction the moment a pay stub arrives. grossPay and netPay populate the income fields directly, the YTD fields feed the same cross-check a human reviewer would have run by hand, and warnings routes the handful of genuinely uncertain documents to a reviewer instead of all of them. The reviewer's job shifts from re-typing numbers to judging edge cases, which is a better use of a trained underwriter's time either way. The same pattern holds for an HR team onboarding a transferring employee, or a payroll audit diffing a sample of stubs against a company's own payroll register.

Where to Start

If the documents in question are genuinely pay stubs or payslips, the named parser is the faster path. No schema to design, no field mapping to maintain, just a document in and the field list above back out. Test it against real stubs from whichever payroll providers your actual documents come from, since format variation between providers is exactly the problem this parser is built to absorb, and build your error handling around warnings and fallbackUsed rather than only the happy-path fields. Reach for the Analyzer-based route the moment the documents stop being standard pay stubs.

Website: pdf4me.com
Documentation: docs.pdf4me.com

What Does an AI Mortgage Document Parser Actually Return? Loan Terms, Borrower Info, and Closing Details Explained

PDF4me — Tue, 06 Oct 2026 12:45:03 +0000

What Does an AI Mortgage Document Parser Actually Return? Loan Terms, Borrower Info, and Closing Details Explained

Hand a mortgage file to a generic OCR tool and you get a transcript: every character on every page, roughly in reading order, with no idea which number is the loan amount and which one is the appraised value. That distinction is the whole job in a loan-processing or compliance pipeline, where the next system in line needs loanAmount in one field and appraisedValue in another, not forty pages of text it has to re-read itself. A mortgage package makes this worse than almost any other document type, because it is not one document. It is a stack: a promissory note, a deed of trust, an appraisal, a closing disclosure, sometimes a title report, each with its own layout and its own vocabulary for the same underlying facts. So what does a purpose-built mortgage document parser actually hand back, and why does its field list look the way it does?

Why a Transcript Is Not a Loan File

Lenders, servicers, and the software vendors who build for them do not want text. They want a loan amount they can run a calculation against, a closing date they can schedule a disbursement around, and a borrower name they can match to an existing record, every time, regardless of which title company or loan origination system produced the page. A generic OCR engine reads a mortgage document correctly as characters and still leaves someone to figure out which string means what, document by document, lender by lender. That is the gap PDF4me's AI Mortgage Document Parser is built to close. According to its own product description, it uses "machine learning to extract structured data from mortgage documents," which in practice means it understands mortgage paperwork well enough to return loan terms, borrower details, and closing information as named fields, not as a page of recovered text.

The Response Shape, Field by Field

Send the parser a mortgage document as a PDF, PNG, JPG, or JPEG, and the response groups into several clear categories. I live-checked the field list directly against PDF4me's own Power Automate and n8n integration docs for this action rather than trusting a single summary table, and it is worth doing the same before you wire anything to it, because the two pages don't phrase the grouping identically even though the field names match.

Loan information: documentType, lenderName, loanAmount, interestRate, loanTerm, loanType, effectiveDate.

Borrower details: borrowerName, coBorrowerName, employerName, position, income, employmentStatus, employmentStartDate.

Property and appraisal: propertyAddress, legalDescription, propertyType, conditionRating, appraisedValue, appraiserName, appraiserLicenseNumber, plus a comparableSales array holding each comparable's address, sale price, sale date, and adjustments.

Closing and title: closingCosts, cashToClose, settlementAgent, closingDate, disbursementDate, currentOwner, liensAndEncumbrances, easements, titleInsuranceAmount, propertyTaxesStatus.

Payments and compliance: a projectedPayments array (one entry per payment type, each carrying principal and interest, mortgage insurance, estimated escrow, and the estimated total monthly payment), plus notarySignatureWitness, controlNumber, parish, currency, witnessName, witnessType, preparerCompany, homesteadActCompliance, farmLandActCompliance, and a handful of lien-related flags: securesLiabilities, guaranteeMortgage, collateralMortgage.

Processing metadata on every response: success, message, warnings, fallbackUsed, jobId, jobIdExt. Check success and warnings before you trust anything else in the payload; a response with fallbackUsed: true is telling you the extraction took a lower-confidence path on at least one field.

A roughly shaped (not literal) version of what comes back looks like this:

{
  "documentType": "Deed of Trust",
  "lenderName": "Example Lending Co.",
  "loanAmount": 285000.00,
  "interestRate": 6.125,
  "loanTerm": 30,
  "borrowerName": "Jane A. Doe",
  "propertyAddress": "412 Elm Street, Springfield",
  "appraisedValue": 310000.00,
  "closingCosts": 6420.15,
  "cashToClose": 14200.00,
  "settlementAgent": "Example Title & Escrow",
  "closingDate": "2026-11-14",
  "comparableSales": [
    { "address": "398 Elm Street", "salePrice": 305000.00, "saleDate": "2026-08-02" }
  ],
  "projectedPayments": [
    { "principalAndInterest": 1732.21, "mortgageInsurance": 0.00, "estimatedEscrow": 410.00, "estimatedTotalMonthlyPayment": 2142.21 }
  ],
  "success": true,
  "warnings": [],
  "fallbackUsed": false,
  "jobId": "a1b2c3d4-...",
  "jobIdExt": "ext-..."
}

That is well over forty named fields spanning seven real-world categories a loan file actually has, returned from one call instead of built field by field in a mapping layer. One flag worth knowing before you quote a number in your own docs or a blog post: the n8n documentation page labels its own field list "30 total" while enumerating closer to fifty individual fields across those same categories. The discrepancy looks like a stale summary count on PDF4me's side rather than a real difference in what the parser returns, so pull one live response and count the fields yourself before repeating an exact number.

Two Inputs That Change What You Get Back

Two optional parameters are worth knowing before the first run. documentType lets you tell the parser what kind of mortgage paperwork it is looking at, such as "Deed of Trust," "Promissory Note," "Mortgage Agreement," or "Loan Application," which the documentation says improves extraction accuracy. That makes sense: a promissory note and a title report share almost none of the same layout, so telling the parser which one it is looking at upfront removes a layer of guessing.

customFieldKeys goes further. It is an array of additional field names, beyond the standard schema above, that this specific pipeline needs. A servicer tracking an internal risk score or a regional disclosure code the standard schema does not cover can request it through this parameter rather than waiting on a schema update. That is a meaningfully different model from a rigid, fixed-output parser, and it is one of the more useful details buried in the request body rather than the headline feature list.

The Same Action, Four Ways In, Three Ways to Hand It a File

The AI Mortgage Document Parser is not REST-only. It ships as a native action in Power Automate, a native module in Make, a native node in n8n, and a native action in Zapier, with the same required inputs and the same output schema across all four.

In Power Automate, the file comes in as binary content through Mortgage Document File Content, mapped straight from a connector like SharePoint, OneDrive, Dropbox, or an email attachment, alongside the required Mortgage Document Name, which matters for a loan-ops team that already lives in Microsoft 365 and wants the extracted fields to land directly in a SharePoint list or a Dynamics 365 record without a custom connector in between.

n8n's node, named "AI-Process Mortgage Document," is the most explicit about this choice: an Input Data Type parameter switches between Binary Data (reads from a previous node's binary output via Input Binary Field), Base64 String (via Base64 Mortgage Document Content), and URL (via Mortgage Document URL) and the filename always goes in separately through Mortgage Document Name. Make exposes the same three input modes under its own field names. In Zapier, a mortgage PDF dropped into a watched folder can turn into a fully structured record in a CRM or spreadsheet with no code written at all.

That consistency matters more than it sounds. A pipeline built once against this schema in Make can be rebuilt in n8n, or handed to a no-code teammate in Zapier, without anyone re-learning what closingCosts or settlementAgent means, because the field names do not change between platforms. The parser itself reportedly handles both scanned and digitally generated documents without altering the source file, which is the detail that actually matters if the original has to go into a compliance archive untouched. That handling claim comes from PDF4me's own integration documentation rather than from independently observed test output in this piece, so treat it as the vendor's stated behavior pending your own verification against a real scanned file.

When a Fixed Schema Is Not Enough

The Mortgage Document Parser works because its schema is already built for one document family. But not every document a developer needs to parse is a mortgage, and PDF4me's broader AI lineup reflects that: it sits alongside dedicated parsers for pay stubs, tax documents, receipts, and purchase or sales orders, each with its own fixed schema tuned to that document type. For anything outside those categories, there is a second mechanism worth knowing about: the generic AI Document Parser, which runs against an Analyzer you define yourself in the PDF4me dashboard, with your own field names, types, and descriptions, called by an AnalyzerId instead of a fixed schema. Edit that schema later and every workflow pointed at the same Analyzer ID picks up the change automatically, with no Zap or flow to rebuild. Choosing between the two is really a question of fit: reach for the Mortgage Document Parser when the document family is already mortgage paperwork and the standard fields cover the job, and reach for a self-defined Analyzer when the document type is something the standard parsers were never built for.

Worth noting for anyone looking for a plain REST endpoint: there is no dedicated pdf4me-api page for this specific parser outside the four integration platforms above (confirmed as a 404 on the expected path while researching this piece). If that changes, it will show up alongside the other pdf4me-api endpoints in the documentation.

Where to Start

If a lending, servicing, or proptech pipeline currently has a human opening PDFs to copy numbers into a loan system, this is the kind of task that disappears first. One call, one of four platforms, and a loan amount, a closing date, and a borrower name that were never typed by hand.

Website: pdf4me.com
Documentation: docs.pdf4me.com

Why Would an API Parse Marriage Certificates? Inside PDF4me's Government-Document Parser

PDF4me — Tue, 06 Oct 2026 06:57:21 +0000

Why Would an API Parse Marriage Certificates? Inside PDF4me's Government-Document Parser

Look at PDF4me's list of pre-built AI document parsers and eleven of them make instant sense. Invoices, bank statements, bank cheques, contracts, credit cards, health cards, pay stubs, tax documents, purchase orders: these are the documents every finance, ops, or back-office team drowns in daily. Then there's number seven on the list: a dedicated AI Marriage Certificate Parser. Next to a pile of invoices and tax forms, that one looks like it wandered in from a different product.

It didn't. A marriage certificate is a government-issued document with a fixed set of fields, issued in enormous volume, read by humans who then type what they see into a database by hand. That is exactly the problem every other parser on that list solves. The only thing unusual about this one is that most developers never think to ask whether an API can handle it.

Who actually needs to parse a marriage certificate by API?

Not a wedding photographer. The real demand comes from the systems that have to verify a marriage happened before they'll do something else. A mortgage lender underwriting a joint application needs to confirm both borrowers are legally married before combining income. An insurer processing a beneficiary change or a dependent enrollment needs the same proof. HR and benefits platforms need it when an employee adds a spouse to health coverage. Immigration and visa processing needs it as supporting evidence. County clerk offices digitizing decades of paper archives need it just to make old records searchable. None of these are edge cases. They are recurring, document-heavy workflows that currently run on someone opening a PDF or a scanned image and retyping names, dates, and certificate numbers into a form.

That retyping step is where the real cost sits, and it is the same cost PDF4me's other eleven parsers were built to remove. The marriage certificate just happens to live in government and vital-records workflows instead of finance ones.

Think about how a mortgage underwriting team actually handles a joint application today. Someone opens the uploaded scan, squints at a certificate that might be forty years old, typed on a county clerk's letterhead that changed its layout twice since then, and copies a certificate number and two names into the loan origination system by hand. Multiply that by every joint application that month. It's the same bottleneck an AP team has with invoices, just wearing a different outfit.

What the parser actually extracts

This isn't OCR with a label slapped on it. The Marriage Certificate Parser is a pre-tuned schema, one of twelve PDF4me maintains across its AI Document Parser line, so a developer never builds or trains an extraction template themselves. According to PDF4me's AI products page, you pick the parser that matches your document type and get structured JSON back, with no template maintenance on your side.

For marriage certificates specifically, the schema pulls more than thirty structured fields in a single call. A typical response includes fields like:

{
  "success": true,
  "certificateNumber": "MC-2024-0198273",
  "dateOfMarriage": "2024-06-14",
  "placeOfMarriage": "Cook County, Illinois",
  "issuingAuthority": "Cook County Clerk's Office",
  "spouse1FullName": "Jordan A. Reyes",
  "spouse1BirthDate": "1991-03-02",
  "spouse2FullName": "Taylor M. Chen",
  "spouse2BirthDate": "1990-11-19",
  "officiantName": "Rev. Marcus Doyle",
  "officiantLicenseNumber": "OFF-88213",
  "witnesses": ["Priya Natarajan", "Daniel Osei"],
  "authenticityIssues": [],
  "fraudIndicators": [],
  "authenticityRecommendation": "No tampering indicators detected"
}

That field set (certificate identifiers, both spouses' details, officiant information, witness names, and document verification signals) maps directly onto what's live and verified on PDF4me's own Make integration page for this parser, confirmed field by field: certificateNumber, dateOfMarriage, placeOfMarriage, issuingAuthority, spouse1FullName, spouse1BirthDate, spouse2FullName, spouse2BirthDate, officiantName, officiantLicenseNumber, and witnesses, plus the optional authenticityIssues, fraudIndicators, and authenticityRecommendation fields from the fraud check.

There's also an optional authenticity check built into the same call. Toggle it on and the parser returns fraud indicators, tampering signals, and a recommendation alongside the extracted data, useful anywhere a forged or altered certificate would be a real liability, like loan underwriting or benefits fraud review. If a field can't be confidently read, the response includes warnings instead of silently guessing, so a low-confidence extraction doesn't masquerade as a clean one.

That matters more for this document type than most. An invoice from any vendor roughly follows the same layout logic: a header, line items, a total. A marriage certificate does not. Formats vary by state, by country, by decade, by whether the record was typed, handwritten, or stamped. A regex pattern tuned for one county clerk's template breaks the moment a different jurisdiction's certificate shows up. That's precisely the kind of document where a pre-tuned, maintained schema earns its keep over a brittle, hand-rolled extraction script. Nobody wants to own a growing pile of jurisdiction-specific regex just to keep a benefits-enrollment pipeline running.

The authenticity check is worth sitting with for a second, because it's doing something different from the extraction itself. Extraction answers "what does this certificate say?" The fraud and tampering signals answer a separate question: "should I trust what it says?" Those are two different risk surfaces, and most teams building their own extraction script only ever solve the first one. A hand-rolled parser will happily hand you a clean-looking certificate number off a certificate that's been altered, because nothing in a basic text-extraction pipeline is looking for tampering in the first place. Bundling both checks into one call means a lender or insurer gets a usable answer to both questions without standing up a second system.

How you'd actually wire this in

PDF4me doesn't make you choose between a REST call and a no-code workflow tool. The same Marriage Certificate Parser is available as a native action across multiple surfaces, and you pick whichever fits the system you're already building in.

On Power Automate, it's a connector action that takes the certificate's file content and filename (PDF, PNG, JPG, or JPEG all work) straight from SharePoint, OneDrive, email, or Dropbox, no separate upload step required. On Make, the AI-Process Marriage Certificate module accepts the same file either as binary data, a Base64 string, or a public URL, and returns the JSON payload shown above, ready to drop into the next step of a scenario. On n8n, the node slots into a workflow the same way, pulling binary data from a prior node or a public HTTPS URL and returning structured JSON plus any warning or fallback-extraction flags. And on Zapier, the same AI Marriage Certificate Parser action handles PDF or image input and returns the full field set, with that page explicitly calling out vital records management, identity verification, insurance claims processing, immigration and visa services, and healthcare record management as its use cases. That's about as direct a confirmation as you'll get that this isn't a novelty parser; it's built for exactly the workflows described above.

In every one of those four surfaces, the input requirements are nearly identical: the file itself and its filename, so the parser can detect the format correctly. Authenticity verification is an optional toggle in all of them, not a separate product. That consistency is the point. Whether your team automates in a low-code tool or calls an endpoint directly from your own backend, you're hitting the same underlying schema and getting the same field set back, which means switching tools later doesn't mean re-learning the output shape.

One thing worth planning for before you wire it in

A marriage certificate carries more personally identifiable information per page than most of the documents developers are used to feeding into an API: full names, birth dates, ages, home addresses, and a government-issued certificate number, all in one payload. That's not a reason to avoid the parser, it's a reason to think about where the extracted JSON lands once the call returns. If your workflow writes the response straight into a loan file, an HR record, or a benefits database, that's exactly where this data is supposed to end up. If it's getting logged, cached, or passed through an intermediate step for debugging, it's worth treating that output the same way you'd treat any other field full of names and birth dates in your system, rather than assuming it's just another JSON blob because it came back from a document parser instead of a form.

The part that's easy to miss

The interesting lesson here isn't really about marriage certificates. It's that "document AI" has quietly stopped being synonymous with "invoice AI." The moment a document is structured, government-issued, high-volume, and currently processed by a human retyping fields into a system, it's a candidate for this kind of parser, whether that document is a certificate, a cheque, a pay stub, or something your team hasn't thought to automate yet. The marriage certificate parser looking out of place on that product page is actually the tell: if PDF4me built a dedicated, pre-tuned schema for something this specific, it's worth checking whether a similarly "unglamorous" document in your own pipeline already has one too, rather than assuming extraction tooling stops at finance paperwork.

If you're weighing whether to build your own extraction logic for a government or vital-records document versus reaching for a parser that already exists, the honest comparison is maintenance, not just the first integration. A pre-tuned schema that PDF4me keeps current across jurisdictions and formats is a very different ongoing cost than a regex library your own team has to keep patching every time a new certificate layout shows up.

Website: pdf4me.com
Documentation: docs.pdf4me.com

What Does an Insurance Card Parser Return? Member ID, Plan, and Rx Data Explained

PDF4me — Mon, 05 Oct 2026 18:28:51 +0000

Hand a health insurance card to a generic OCR tool and you will get a transcript: every character on the card, in roughly the order it appeared, with no idea which string is the member ID and which is the group number. That distinction matters enormously in a benefits-verification or claims-intake pipeline, where the next system in line needs memberId in one field and rxBin in another, not a wall of text it has to re-parse itself. So what does a purpose-built insurance card parser actually hand back, field by field, and how do you build on top of it?

Why a Transcript Is Not the Same Thing as Structured Coverage Data

Insurance cards are dense by design. A single card can carry a member's identity, their plan classification, their group affiliation, a coverage start date, and a separate set of prescription routing codes that have nothing to do with medical coverage at all. None of that is labeled consistently across insurers. One carrier prints "Member ID" top left; another buries it under a barcode. One spells out "Rx BIN" in full; another abbreviates it to three characters next to a logo. A generic OCR engine reads all of that correctly as text and still leaves you the job of figuring out which string means what, for however many insurer layouts your intake pipeline has to handle.

That is the specific problem PDF4me's AI Health Card Parser is built to close. It does not stop at reading characters. It understands the structure of a health insurance card well enough to return member identity, plan details, and prescription routing data as named fields, regardless of which insurer issued the card or how that insurer chose to lay it out.

The Documented Inputs

The action's own Power Automate documentation lists exactly three inputs:

Health Card File Content (binary, required): the card as a PDF, PNG, JPG, or JPEG, typically mapped from a prior "Get file content" step, SharePoint, OneDrive, or an email attachment.
Health Card Name (string, required): the filename, including its extension, used for format detection.
customFieldKeys (array, optional, under Advanced parameters): additional field names to extract beyond the standard health card data set, for insurers whose cards carry something extra you need captured.

Make and n8n expose the same three inputs under their own node UI, since all three wrap the same underlying parser.

The Exact Response Shape

This is the response example from the Power Automate documentation, quoted verbatim rather than reconstructed from memory, since marketing-page JSON examples elsewhere in this product line have been known to omit fields the real payload sends:

{
  "success": true,
  "message": "Health card processed successfully using AI",
  "processedData": {
    "healthData": {
      "memberId": "M123456789",
      "groupNumber": "GRP001234",
      "planType": "PPO",
      "insuranceProvider": "Blue Cross Blue Shield",
      "memberName": "John Michael Smith",
      "dateOfBirthStr": "1985-03-15",
      "effectiveDateStr": "2024-01-01",
      "rxBin": "123456",
      "rxPcn": "ABC123",
      "rxGroup": "RXGRP001",
      "copayInfo": [
        { "service": "Primary Care", "copay": "$25" },
        { "service": "Specialist", "copay": "$50" },
        { "service": "Emergency Room", "copay": "$200" }
      ],
      "confidence": {
        "memberId": 0.95,
        "memberName": 0.98,
        "insuranceProvider": 0.92
      }
    },
    "status": "Success",
    "errors": [],
    "jobId": "11111111-2222-3333-4444-555555555555"
  },
  "processingTimestamp": "2024-01-15T10:30:45.123Z"
}

Ten named fields under healthData, plus the copayInfo array, nested inside processedData, wrapped with a top-level success flag and a jobId for tracking. Note that the sample's confidence block only lists three of the ten fields explicitly; treat that as illustrative rather than exhaustive, and check for a confidence value on every field your flow actually depends on before trusting it blankly.

Processing the Response: Branch on Confidence, Don't Trust It Blankly

The field worth writing real code around is confidence, not just healthData. A card with a crisp, high-resolution member ID and a slightly smudged group number can come back with a confidence near 1.0 on the first field and meaningfully lower on the second, in the same response. Here is a small Python helper that takes the parsed JSON above and splits fields into "safe to auto-process" and "needs a human" based on a threshold:

def split_by_confidence(response_json, threshold=0.85):
    health_data = response_json["processedData"]["healthData"]
    confidence = health_data.get("confidence", {})

    auto_processed = {}
    needs_review = {}

    for field, value in health_data.items():
        if field in ("confidence", "copayInfo"):
            continue
        score = confidence.get(field)
        if score is None:
            # No confidence reported for this field -- treat as needing review
            needs_review[field] = value
        elif score >= threshold:
            auto_processed[field] = value
        else:
            needs_review[field] = (value, score)

    return auto_processed, needs_review

Wire that into a Power Automate, Make, or n8n flow and the branch becomes mechanical: everything in auto_processed writes straight to the benefits record, everything in needs_review goes to a queue a human glances at, one field at a time, instead of the whole card getting rejected over a single low-confidence value. That is the difference between a parser that looks good in a demo and one that survives contact with a real intake pipeline, where card quality varies and insurers don't agree on layout.

Why This Beats Building a Template for Every Insurer

The honest alternative to a pre-built parser is building a template, or a set of regex patterns, for every insurer layout your pipeline needs to handle, then maintaining that set as insurers redesign their cards. That works until the third or fourth carrier, at which point the maintenance burden starts to outweigh the time saved by automating in the first place. The AI Health Card Parser is pre-tuned specifically so that step never has to happen: there is no template to create and no field positions to configure before the first card goes through it.

It's worth being precise about what kind of parser this is, because PDF4me ships more than one shape of AI extraction. The Health Card Parser is a pre-built, pre-tuned extractor with a fixed schema: send a card, get back the fields above, nothing to configure first. That's different from PDF4me's generic AI Document Parser using a custom Document Schema, where you define your own JSON schema and field list in the dashboard for document types that don't have a dedicated pre-built parser yet. If your document is a health insurance card, the pre-built parser is the faster and more accurate path; the custom schema route exists for everything outside PDF4me's current catalog of pre-built parsers.

A Worked Scenario: Telehealth Intake

Consider a telehealth platform that asks a new patient to photograph the front of their insurance card during signup. Before a parser like this existed, that photo either sat in storage until an intake coordinator manually typed the member ID and group number into the practice management system, or the platform skipped verification entirely and found out the coverage details were wrong only when a claim bounced back weeks later.

Run that photo through the parser instead: memberId, memberName, and dateOfBirthStr populate the patient record directly. planType and insuranceProvider determine which eligibility check runs next, since a PPO and an HMO often route through different downstream verification steps. rxBin, rxPcn, and rxGroup, if the visit involves a prescription, hand off straight to the pharmacy benefits check, separately from the medical coverage check, because those two checks genuinely don't share a code path. Pair every one of those handoffs with the split_by_confidence logic above, and a low-confidence groupNumber gets flagged for a quick human glance instead of silently feeding a wrong value into an eligibility check that fails for reasons nobody can trace back to the original card photo.

Where It Drops Into an Existing Flow

Because the Health Card Parser is a native action in Power Automate, Make, and n8n, it slots into an existing intake flow rather than requiring a new one built around it. A Power Automate flow can take an uploaded card straight from a SharePoint library or a Forms submission; a Make scenario can start from a webhook trigger; an n8n workflow can sit inside a larger patient-onboarding chain next to whatever CRM or EHR integration already exists. None of the three requires writing a schema first, because the schema is already built into the parser itself.

That's the trade this specific parser makes against PDF4me's more general, schema-driven Document Parser: less flexibility for documents that don't fit the health card mold, in exchange for zero setup time for the ones that do, and a response shape you can start writing confidence-aware logic against the moment the first card comes through.

Website: pdf4me.com
Documentation: docs.pdf4me.com

How to Extract Card Number, Expiry, and Cardholder Name from a Credit Card Image via API

PDF4me — Thu, 01 Oct 2026 15:41:37 +0000

How to Extract Card Number, Expiry, and Cardholder Name from a Credit Card Image via API

Somewhere in your company right now, someone is looking at a photo of a credit card and typing the number into a spreadsheet by hand. Maybe it's a reimbursement form. Maybe it's a KYC check during account setup. Maybe it's a vendor onboarding packet where a scanned card sits next to a dozen other documents nobody wants to open individually. Whatever the reason, that number gets retyped, and retyping sixteen digits by hand is exactly the kind of task that produces a transposed digit on a Friday afternoon.

PDF4me's AI Credit Card Parser exists to take that step out of the loop entirely. Point it at a credit card image, scan, or PDF, and it returns the card number, expiry date, cardholder name, and brand as structured, mappable fields, ready to drop into whatever system is waiting downstream. It's one of twelve pre-tuned document parsers PDF4me ships on its AI products page, sitting alongside parsers for bank statements, insurance cards, mortgage documents, and tax forms. Each one is purpose-built for a document type people deal with constantly and rarely enjoy processing manually.

What the parser actually returns

The core extraction is consistent across every platform PDF4me supports it on: card number, expiry date, cardholder name, and card type or brand (Visa, Mastercard, and so on). From there, the field list gets more generous depending on which integration you're using. The Power Automate action adds issuing bank, an associated account number, and valid-from and valid-through date ranges. The Make module and the Zapier action both extract a CVV field too, when one is visible on the document, alongside the same bank and account details. The n8n node returns everything inside a single creditCardData object rather than a flat field list, which is worth knowing before you start mapping variables in a workflow.

Here's roughly what that structured output looks like once it lands in your workflow, assembled from the field names documented across Power Automate, Make, n8n, and Zapier (illustrative shape, not a copy-pasted sample payload):

{
  "success": true,
  "fields": {
    "cardNumber": "4111 1111 1111 1111",
    "expiryDate": "09/29",
    "cardholderName": "J SAMPLE",
    "cardType": "Visa",
    "cardBrand": "Visa",
    "issuingBank": "Example Bank",
    "accountNumber": "",
    "validFrom": "",
    "validThru": "09/29"
  },
  "warnings": [],
  "fallbackUsed": false
}

Every version of the extraction ships with a quality layer worth paying attention to. Alongside the fields themselves, the response includes a warnings array flagging anything the parser wasn't confident about, and a fallbackUsed boolean telling you whether it had to fall back to a secondary extraction method to get a result. If a field genuinely can't be read off the image, n8n's documentation specifically notes it comes back as an empty string rather than a missing key, which matters if your downstream logic checks for the field's presence instead of its value.

There's also a customFieldKeys parameter available across Power Automate, Make, n8n, and Zapier. It's the escape hatch for anything the standard field set doesn't cover, letting you ask the parser to also look for a loyalty number, an internal reference code, or whatever else happens to appear on the card alongside the standard fields.

Why this isn't a payment processor, and why that matters

Here's the part worth reading twice before you wire this into anything customer-facing: PDF4me's own documentation is explicit that this tool "does not process transactions and carries no PCI DSS certification." It reads a card image and gives you back structured text. It does not authorize a charge, store a card on file for future billing, or meet the compliance bar that actual payment processing requires.

That's not a knock on the feature. It's a scope boundary, and a sensible one. A document parser and a payment gateway solve different problems, and conflating them is how companies end up with compliance headaches nobody budgeted for. If your workflow needs to actually charge a card, this sits upstream of that, feeding a real payment processor or your existing PCI-compliant systems, never replacing them.

What this does solve well is everything adjacent to the actual transaction. Expense reports where an employee photographs a receipt and a card. Vendor onboarding where a scanned document needs its payment details logged for internal records. Reconciliation workflows where someone needs to match a statement line to a card type without opening the statement themselves. None of those require PCI scope. All of them currently involve someone typing numbers from a screen into a form.

Wiring it into your automation platform of choice

The shape of the workflow is nearly identical no matter which platform you're building on, which is worth knowing if your team runs more than one of them. You need two inputs: the file itself (as binary data, a base64 string, or in some integrations a public URL) and the filename with its extension intact, since PDF4me uses that extension to pick the right processing path. Supported formats are PDF, PNG, JPG, and JPEG across every platform.

In Power Automate, that means a File Content field and a filename parameter feeding straight into the AI Credit Card Parser action, with the structured output available as dynamic content for whatever comes next, routing it into a SharePoint list, a Dataverse table, or an approval flow. In Make, the module accepts binary data pulled straight from a Dropbox or Google Drive watch, a base64 string, or a public URL, and the resulting creditCardData object comes back as individually mappable tokens you can route anywhere in the scenario, including validation steps before anything touches a payment or ERP system. The Zapier action works the same way with a Credit Card File and Credit Card Name as its required inputs, which plugs neatly into a Zap that starts with a new email attachment or a form upload. And the n8n node wraps the whole thing into one action step, taking your PDF4me API credential and the same input options, then handing back creditCardData plus a jobId and jobIdExt you can use for tracking if the workflow needs to check on a longer-running extraction later.

None of these require you to write a parsing library, train a model on card layouts, or maintain regex patterns for every card network's formatting quirks. You're wiring an action into a trigger, not building an extraction pipeline.

Handling the fields you shouldn't keep

Getting a full card number back as clean, structured text is useful and also exactly the kind of thing that should make you pause before deciding what to do with it next. The responsible default is to treat the raw card number and any CVV field as transient: use them for the one step that needs them, mask or drop them immediately after, and store only what you actually need long-term, which for most internal workflows is a last-four reference and the card brand, not the full number.

PDF4me's own n8n documentation puts this plainly, advising teams to drop sensitive fields immediately rather than storing full card data at rest. That's good practice regardless of which platform you're on. If your automation writes the extracted fields into a spreadsheet, a CRM, or a database table, that's the moment to decide what actually needs to persist versus what was only ever needed transiently to complete one step in the workflow.

Where this actually fits

The honest use case here isn't "replace your payment processor." It's closer to "stop making a human retype sixteen digits from a photo." Expense management tools that currently ask employees to manually enter card details alongside a receipt. Onboarding workflows that collect a scanned document and need its payment reference logged without anyone opening the file. Internal reconciliation processes where a card type and partial number need to get matched against a statement, and the rest of the data was never going to be used for anything beyond that match.

If your team is already running Power Automate, Make, Zapier, or n8n for other document workflows, adding the Credit Card Parser is the same pattern you've already built elsewhere: a trigger, this action, and a destination for the structured result. It's worth testing against a handful of real card images and scans first, since the quality warnings and fallback flag exist precisely because card layouts, lighting, and image quality vary more than, say, a standardized invoice format does.

Website: pdf4me.com
Documentation: docs.pdf4me.com