Track Changes in Word Documents Your Users Never Opened in Word

A contract goes out for review. Three people edit it, in three different tools, over three different days. By the time it comes back, somebody has to answer a simple question: what actually changed? The traditional answer is opening Word, turning on the Reviewing pane, and scrolling through a wall of colored strikethroughs by hand. That works fine for one document. It falls apart the moment "somebody" is a workflow instead of a person, and the review pipeline needs to know what changed without a human ever double-clicking a .docx file.

PDF4me splits that problem into two separate API calls, and understanding why they're separate is most of what matters here.

Turning tracking on before anyone edits

The first call is Enable Tracking Changes, POST /api/v2/EnableTrackingChangesInWord. It takes a Base64-encoded DOCX (docContent), its filename (docName), and an optional async flag worth setting to true on larger files, since PDF4me then processes the document as a background job instead of holding the connection open. It returns the same document, as a file, with Track Changes switched on at the document level. It doesn't add any revisions itself. There's nothing to track yet. What it does is flip a setting inside the file so that whoever edits it next, in Word, in a Word-compatible editor, wherever the file lands, has their edits recorded as tracked revisions automatically, whether they remember to turn the feature on themselves or not.

Here's the request, live-verified against PDF4me's own Python sample rather than typed from a docs page alone:

import base64
import requests

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

url = "https://api.pdf4me.com/api/v2/EnableTrackingChangesInWord"
headers = {
    "Authorization": "Basic YOUR_API_KEY",
    "Content-Type": "application/json"
}
payload = {
    "docName": "contract.docx",
    "docContent": encode_docx("contract.docx"),
    "async": True
}

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

if response.status_code == 200:
    with open("contract-tracked.docx", "wb") as f:
        f.write(response.content)
elif response.status_code == 202:
    # Large file: poll the Location header URL until it returns 200
    poll_url = response.headers["Location"]

That distinction matters more than it sounds like it should. Track Changes is normally something a person has to remember to click on before they start editing, and reviewers forget constantly. Enabling it programmatically before the document ever reaches a human means the setting is baked into the file itself. Nobody has to remember anything. A contract generation pipeline, a document-handoff step in an approval workflow, or an onboarding packet generator can all call this once, right after the document is created, and every downstream edit gets captured whether the editor thinks about revision tracking or not.

Reading the changes back out, without opening Word

The second call is where the "never opened in Word" part of this actually happens. Get Tracking Changes, POST /api/v2/GetTrackingChangesInWord, takes the same shape of input, docContent, docName, the same optional async flag, but this time the document already has tracked edits in it. Instead of handing back a modified file, it returns structured JSON.

url = "https://api.pdf4me.com/api/v2/GetTrackingChangesInWord"
payload = {
    "docName": "contract-tracked.docx",
    "docContent": encode_docx("contract-tracked.docx"),
    "async": True
}

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

if response.status_code == 200:
    changes = response.json()
elif response.status_code == 202:
    # Large file: poll the Location header URL until it returns 200
    poll_url = response.headers["Location"]

Instead of handing back a modified file, the response returns structured JSON. Each tracked change comes back as its own entry: the type of edit, the affected text, who made it, and where in the document it landed. PDF4me's own documentation isn't fully consistent on the exact field names across every surface (the REST reference, the Power Automate action, and the Zapier action each describe the fields slightly differently), so confirm the precise shape for your integration with the interactive API Tester, linked below, before writing parsing code against it, rather than trusting any one page's example verbatim.

That's the whole point. A reviewer no longer needs Word installed, doesn't need to open the Reviewing pane, and doesn't need to scroll through a document by eye to find what moved. The tracked edits arrive as data. A workflow can loop over the returned changes and flag every change froma specific author, count how many edits a document picked up before approval, build a plain-English summary of what changed without rendering the document at all, or route a document to a different approver depending on whether the changes were minor insertions versus something more substantial. None of that is possible by staring at a.docx` file. It's trivial once the changes are JSON instead of colored text.

What actually happens between those two calls

It's worth being precise about what these two endpoints don't do, since it's easy to assume more than they promise. Enabling Track Changes doesn't retroactively track edits that already happened before the call ran. It only affects edits made after the setting is switched on. And Get Tracking Changes only returns what Word's own Track Changes mechanism recorded. If someone edited the document with tracking off, or accepted and cleared changes before the extraction call ran, there's nothing left to extract. The API is reading the document's own revision metadata, not reconstructing history that was never captured.

There's a third, related endpoint worth knowing about even though it's not this article's main focus: Disable Tracking Changes turns the setting back off, the natural close to the loop once a document has been reviewed and its tracked edits pulled out as data. A generation-review-finalize pipeline would typically call Enable right after creating the document, Get once review is complete, and Disable right before the document is archived or sent out as a clean final copy.

Where this fits in an actual workflow

The shape that keeps showing up is document generation feeding straight into review. A contract gets generated from a template, Track Changes gets enabled on it in the same pipeline run, it goes out to whoever needs to mark it up, and when it comes back, a workflow calls Get Tracking Changes instead of routing it to a person just to check whether anything substantive changed. Legal teams use a version of this to triage which contracts actually need a lawyer's attention versus which ones only picked up minor edits. HR teams use it on offer letters and policy documents that go through multiple rounds of stakeholder review before anyone signs off. Editorial and documentation teams use it to see which sections of a draft got touched, without diffing the whole file by hand.

If you want to see the request and response shapes before wiring this into anything, PDF4me's interactive API Tester covers both halves of the flow directly: Enable Tracking Changes and Get Tracking Changes each let you upload a real DOCX and watch the actual response come back, which is a faster way to understand the JSON shape than reading a parameter table cold.

And if the rest of your pipeline already lives inside a no-code automation tool rather than raw REST calls, both endpoints are available as native steps. For enabling tracking: Power Automate, Make, Zapier, and n8n all expose it directly. For extracting the tracked changes back out as structured data: Power Automate, Make, Zapier, and n8n each have their own node or module for it too, no Base64 handling required.

Before any of this, your app needs to authenticate against the API in the first place. That's covered in Connect to the PDF4me V2 API, which walks through the base URL, the Basic auth header, and the request and response format the whole V2 API shares.

What this isn't

Enable and Get Tracking Changes work on a single document's own internal revision history. They don't compare two separate document versions against each other the way a redlining tool does. If what you actually need is a diff between two independently edited files rather than the tracked-changes metadata already living inside one file, that's a different feature entirely, worth its own separate look rather than assuming these two endpoints stretch to cover it.

The lifecycle these two endpoints support is narrow and deliberate: switch tracking on before anyone touches the document, read the recorded edits back out as data once review is done, skip the part where a human has to open Word just to find out what changed.

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