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