Somewhere in your company there is a Word document with a Developer tab open, a handful of content controls dropped in, and a name like intake-form-v4-FINAL.docx. It works fine, as long as everyone filling it out has Word. The moment you need to send it to a client, a candidate, or a customer who might be on a phone or a shared kiosk PC, "has Word" stops being a safe assumption. What they do have, almost without exception, is something that can open a PDF.
Convert Word to PDF Form exists for exactly that handoff. You are not redesigning the form. You are not rebuilding it field by field in a separate PDF form builder. You send the Word file you already built, and you get back a PDF where those same fields still work.
What the endpoint actually does
The REST API exposes one endpoint: POST /api/v2/ConvertWordToPdfForm. The request body needs two fields: docContent, the Word file as Base64, and docName, the output filename such as output.pdf. Live-verified against both the REST docs page and the official Python sample in the pdf4me-api-samples repo, which also sends a third field, async, and authenticates with Basic auth against api.pdf4me.com rather than the docs host:
import requests
import base64
api_key = "YOUR_API_KEY"
url = "https://api.pdf4me.com/api/v2/ConvertWordToPdfForm"
with open("intake_form.docx", "rb") as f:
word_base64 = base64.b64encode(f.read()).decode("utf-8")
payload = {
"docContent": word_base64,
"docName": "output.pdf",
"async": True
}
headers = {
"Authorization": f"Basic {api_key}",
"Content-Type": "application/json"
}
response = requests.post(url, json=payload, headers=headers)
if response.status_code == 200:
with open("output.pdf", "wb") as f:
f.write(response.content)
elif response.status_code == 202:
# Async job accepted, poll response.headers["Location"] until 200
pass
Worth flagging: the sample repo's own README describes the request as multipart/form-data, but the actual script it ships sends application/json, exactly like the REST docs page. The script is the one that runs, so that's the version to trust. The API Tester page for this endpoint also references an IsAsync flag rather than the lowercase async the working sample sends; if you're building this by hand rather than starting from the sample, test both field names against your own request in the API Tester before assuming either works.
Authentication otherwise works the same as every other PDF4me REST call: an API key from the PDF4me dashboard. If this is your first PDF4me endpoint, the connect-to-API guide covers the base URL and header format once, for every endpoint after this one.
What actually converts, and where the docs disagree with each other
This is worth reading carefully before you build anything on top of this. PDF4me's own documentation describes what this endpoint preserves in two noticeably different ways, and the more detailed of the two is the more conservative one.
The Make module page is the most specific source available, and it says plainly: the Word document must contain formal content controls inserted through Word's Developer tab, specifically Text controls, Check Box controls, and Drop-Down List controls. Text controls become PDF text input fields, checkboxes stay checkboxes, dropdown controls become PDF combo boxes. Everything else, meaning plain underlined blanks, table cells styled to look like a form, or regular body text, gets rendered as static, non-editable content in the output PDF. Make's own FAQ repeats this twice, in slightly different wording, which reads like a page written by someone who has actually watched this conversion fail on a form that only looked like it had fields.
The REST API page and the Zapier action page, by contrast, both list a longer set of "advanced controls" the endpoint supposedly preserves: rich text fields, file upload fields, calculation fields, digital signature fields, and combo boxes, on top of the standard text, checkbox, dropdown, and date picker set. Neither page explains how you would author a "calculation field" as a native Word content control, and Make's own documentation, which is otherwise the most thorough of the four integration pages, never mentions any of them. Given that the request payload itself is only docContent, docName, and async, there is no parameter that would let you configure which control types to preserve. The most defensible read: the endpoint reliably handles Word's standard content controls, text, checkbox, dropdown, and date picker, and the "advanced controls" list on the REST and Zapier pages describes a broader ambition than a plain Word content control can actually represent. If your form needs something more exotic, test it through the API Tester before you build a workflow around it.
One more distinction worth having straight: this conversion keeps form fields interactive. It does not flatten them. If you need a locked, non-editable copy for archiving or after a signature is collected, that's a separate step, Flatten PDF, chained after this one.
Four ways to put this in a workflow
Make. The Convert Word to PDF Form module needs only a Connection, File Name, and the Document binary. No optional parameters exist. Map File Name with its .docx or .doc extension intact, since that's how the engine identifies the source format, and map Document from whatever preceding module downloaded or generated the file. A typical scenario: a new client record triggers the scenario, Dropbox downloads the intake form template, this module converts it, and Gmail emails the fillable PDF to the client. Chain a Fill PDF Form module afterward to pre-populate any fields, such as a client's name or an event date, before the recipient ever opens it.
Zapier. The Convert Word to PDF Form action takes File Content and File Name as its only required fields, and returns File Content, File Name, File URL, Job Id, and Trace Id. A Zap here might trigger the moment a new Word application form is finalized in Google Drive, convert it, and route the resulting PDF to an applicant tracking system or an email step. Zapier's own tips page is blunt about the most common failure mode: a Word document with underlines or boxed table cells styled to look like a form has nothing for this action to actually preserve, since none of that is a real content control.
Power Automate. The Convert Word to PDF Form action fits naturally into a Microsoft 365 flow: File Content (binary) and File Name are both required, and the connector accepts sources directly from SharePoint or OneDrive. This is a natural fit for HR onboarding paperwork or benefits enrollment forms that already live in a SharePoint library: retrieve the Word template, convert it, and route the resulting fillable PDF to the employee or applicant without anyone touching Word.
n8n. The Convert Word to PDF Form node is the most flexible of the four on input handling. It accepts Binary Data, a Base64 string, or a public URL as the source, useful if your Word templates live somewhere you'd rather reference directly than download through an extra node first. Input File Name, Output File Name, and a Binary Data Output Name are required; an Advanced Options section adds a Custom Profiles field for JSON-based configuration, and the documented example includes a preserveFormFields flag alongside outputDataFormat. Since the base REST payload has no equivalent parameter, treat that flag as n8n-specific until you've confirmed what it changes for your own document. The response comes back with a success boolean, an operation field, and a human-readable message, structured enough to build real error handling around instead of guessing from an HTTP status code alone.
Test it before you automate it
Before wiring this into any of the four platforms above, it's worth confirming the request shape and the actual conversion behavior directly. The Convert Word to PDF Form page in the API Tester lets you send your API key and a Base64 Word document and see the response in the browser, no code required. It's the fastest way to find out, on your own form, whether every content control you expect to survive actually does, before that question surfaces three steps deep in a Make scenario you have to unwind to debug.
What this replaces
The alternative to this endpoint is not usually "no fillable PDF." It's a second, parallel form built by hand in a dedicated PDF form tool, disconnected from the Word document someone in HR, legal, or sales is still the one actually maintaining. Every time that Word template changes, someone has to remember to rebuild the PDF version too, or the two quietly drift apart. Converting from the Word source directly means the form template has exactly one place to live.
One honest gap worth flagging: PDF4me doesn't yet have a dedicated blog walkthrough for this specific endpoint, so beyond the reference docs and the sample repo linked above, that repo is currently the most complete worked example available.
Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com
Top comments (0)