logo

Contract Authenticity Verification API

Detect altered contract terms, changed clauses, and post-signing modifications. A single API call surfaces forensic evidence of PDF tampering — before a contract is executed or relied upon in a dispute.

Contract fraud survives e-signature workflows

E-signature platforms verify that a document was signed, not that it has not been modified since. A common attack: one party signs a contract, the other side opens the PDF in Adobe Acrobat, modifies a clause or payment term, and submits the altered version as the “executed” agreement.

In disputes, the altered contract is presented as legitimate. Without forensic analysis, it is difficult to prove which version was the original and which was modified. Digital signature bypass — where the signature page is preserved but content around it is changed — is especially hard to detect visually.

HTPBE analyzes the binary structure of the PDF, not its visual content. It detects post-signature modifications with “certain” confidence — the highest verdict level in the system — making it suitable for pre-execution verification and dispute investigation.

Common contract fraud patterns

  • Payment terms changed after signature (amount, due date, account)
  • Liability clause modified to shift risk
  • Signature page preserved, contract body replaced
  • Governing law or jurisdiction clause altered
  • Delivery obligations or SLA terms changed
  • Contract date back-dated to claim priority

Forensic signals analyzed in every contract

Five layers of analysis run on every request — results in under 3 seconds

Modifications after signature

The highest-confidence signal: content added to a digitally signed contract. HTPBE returns “certain” confidence when it detects changes that were appended after a valid signature was applied.

Signature removal detection

A signature page can be stripped from a contract and the document re-circulated. HTPBE detects structural evidence of removed signature blocks, also flagged at “certain” confidence.

Incremental update chain

PDF editors append changes to the file rather than rewriting it. Each editing session creates an incremental update record. A contract with multiple incremental updates was modified after original generation.

Execution date inconsistency

The ModDate metadata field updates automatically when a PDF is edited. If the ModDate is later than the contract’s stated execution date or signature date, the document was modified after signing.

Producer tool mismatch

Contracts generated by DocuSign, Adobe Sign, or contract management platforms have consistent producer fields. A producer showing an online PDF editor indicates post-signature processing.

Cross-reference table analysis

Each time a PDF is saved after modification, a new xref table is appended. An authentic, unmodified contract has exactly one xref table. Multiple tables confirm post-generation editing.

Built for legal tech and contract platforms

Add forensic verification to your existing contract lifecycle workflow

Detect content changes made after a contract was digitally signed

Identify incremental updates that indicate post-execution clause modifications

Flag contracts where metadata dates are inconsistent with stated execution dates

Catch signature removal — where a signature page was stripped and the contract re-sent

Integrate into contract lifecycle management and e-signature platforms

Works on any PDF contract — no template matching or original document required

Integrate in minutes

Two calls: POST the PDF URL, then GET the result with specific markers that triggered the verdict.

Request

bash
curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.com/service-agreement-2024.pdf"}'

Result (GET /v1/result/{id})

json
{
  "id": "3f9c8b7a-2e1d-4c5f-9b8e-7a6d5c4b3a21",
  "status": "modified",
  "modification_confidence": "certain",
  "modification_markers": [
    "Modifications detected after digital signature"
  ],
  "producer": "Adobe Acrobat 24.0",
  "creation_date": 1728385200,
  "modification_date": 1728461700,
  "has_digital_signature": true,
  "signature_count": 1,
  "modifications_after_signature": true,
  "xref_count": 2,
  "has_incremental_updates": true
}

Confidence levels: certain means the PDF structure mathematically proves modification (post-signature content, removed signatures, date mismatch). high means strong forensic markers are present. none means no modification detected. When status is inconclusive, the file was created with consumer software that does not allow integrity verification — a signal in itself for contracts, which should come from institutional systems.

Pricing

Self-serve plans. No sales call, no procurement process.

Starter

$15/mo

30 checks/mo

Manual verification for small legal teams

Growth

$149/mo

350 checks/mo

Legal teams processing contracts regularly

Pro

$499/mo

1,500 checks/mo

Contract management platforms and legal tech

Enterprise (unlimited, on-premise available) — see full pricing and docs

Frequently Asked Questions

What's the difference between "modified" and "inconclusive" for a contract?

A modified verdict means the PDF structure contains forensic evidence of post-creation editing — extra xref tables, incremental updates, or post-signature changes. An inconclusive verdict means the contract was generated with consumer software (Microsoft Word, Google Docs) rather than a contract management or e-signature platform. For contracts, inconclusive is also a risk signal — enterprise agreements should not be generated by Word and shared without an institutional signature.

Can it detect clause changes if no digital signature was used?

Yes. Digital signature bypass is the highest-confidence signal (certain), but HTPBE detects post-creation modifications on unsigned contracts too. It looks for multiple xref tables, incremental update chains, producer field inconsistencies, and modification dates that post-date the stated execution date. Most contract fraud involves unsigned PDFs or PDFs where the signature page is kept intact while the body is changed.

Does it verify the identity of signatories?

No. HTPBE verifies document integrity, not identity. It can confirm that a digital signature exists and that no content was modified after signing — but it does not verify whether the signatory is who they claim to be. For identity verification, use an identity platform (Onfido, Jumio) alongside HTPBE for document integrity.

How does it handle contracts with multiple revision versions?

HTPBE analyzes the final submitted PDF — not revision history. If a contract went through multiple drafts and the final version was properly generated from a clean save, it will typically return intact. If the final version was produced by editing a previous PDF version (rather than generating fresh from a contract system), the editing traces will be visible in the structure. For version-controlled contracts, the key question is whether the final file was generated cleanly or assembled by editing.

Automate PDF Verification in Your Workflow

REST API with transparent pricing from $15/mo. Self-serve — no sales call required.
Free web tool available for manual checks. Test keys on all plans.

View API Docs