Redlineo

For developers

A document comparison API that returns evidence.

One multipart POST with two versions of a document; one redline back — with the verification verdict in a response header, a whole-file SHA-256 digest you can store, and the machine-readable change-set embedded inside the output itself. Self-hosted: your documents never leave your infrastructure, and nothing is stored between requests.

The whole integration, in one call

POST two files. Read the verdict. Archive the proof.

curl -f -o redline.docx \
  -F "original=@BOP NY LCS initial.xlsx" \
  -F "revised=@BOP NY LCS final.xlsx" \
  -F "renderMode=tracked" \
  https://redline.your-domain.com/api/compare
X-Compare-Verifiedtrue/false — the round-trip verification verdict for this output. Route on it.
X-Compare-Output-SHA256Whole-file digest of the produced output — store it; a file cannot contain its own hash.
X-Compare-WarningsFidelity warnings, URL-encoded — anything that deserves a human glance.
The output is data, not just a document Every produced file embeds pleodox/change-set.json (the change list with coordinates and before/after values), pleodox/metadata.json (extracted filing metadata + assertion verdicts) and pleodox/integrity.json (the per-part SHA-256 manifest, HMAC-signed when configured). A docx/xlsx is a zip: unzip -p redline.docx pleodox/change-set.json — downstream systems classify and route without parsing prose.

Four verbs

Compare, classify, verify, bake.

  • POST /api/compare

    Two versions → verified redline

    Word (.docx/.docm) or Excel (.xlsx) pairs. Tracked changes or baked colors; Excel pairs can also return the colored review copy (outputFormat=xlsx). Options for excerpts, colors, formatting tracking and metadata profiles.

  • POST /api/classify

    One document → checked and sealed

    Metadata extraction + assertions in single-document mode, the scrub policy, an embedded classification record and integrity manifest — with a runtime proof the content is untouched. The intake-gate story →

  • POST /api/verify

    Any produced file → proof

    Everything is recomputed from the uploaded bytes: integrity (ok | failed | missing), origin (HMAC), and the embedded records. No database — the file proves itself.

  • POST /api/bake

    Tracked changes → fixed colors

    Flattens an existing tracked-changes .docx into viewer-independent strikeout/underline colors, with an optional report page that preserves per-change author attribution.

Plus the Alfresco endpoints for in-DMS comparison and verified save-back. All requests are multipart/form-data; errors are always JSON with a plain-language message; interactive OpenAPI docs (Swagger UI) are served on your running instance.

Why self-hosted matters here

An API your security review can approve.

  • ✔Nothing leaves your network. Pure Java on your own servers — no cloud dependency, no third-party processing, no per-seat installs.
  • ✔Nothing stored. Each request is computed and forgotten; documents are processed in memory/temp files and deleted after the response.
  • ✔Deterministic. The same inputs always produce the same redline — reproducible builds for documents, testable in CI.
  • ✔Operationally boring. Upload limits, concurrency caps and timeouts are standard configuration; excess load gets a clear "busy" error, never a hang.

Next

The full reference is in the docs.

Every endpoint, parameter, response header and error shape, with curl examples: REST API reference. Or see what the outputs look like to a human: compare two Word documents · compare two Excel files.

API reference Ask for a walkthrough
  • document comparison API
  • docx compare REST API
  • compare xlsx files API
  • self-hosted comparison API
  • verifiable document comparison