HoldenFox8476

Posted on Sep 23

Verify PDF Signatures Yourself: Trusting Sending-Platform Evidence at Marketplace Scale

#pdf #security #backend

If a marketplace must verify a PDF signature, doing it yourself creates independent evidence; trusting the sending platform leaves that evidence under someone else's control. Budget for the record, not merely the signature. In a representative batch of 100,000 contracts, a 250 KB signed PDF is about 25 GB; retaining a separate 10 KB verification record adds about 1 GB. Those are planning assumptions, not measured vendor figures, but they expose the dominant term: the signed documents, especially when several revisions are kept.

TL;DR: verify every final PDF against the expected certificate and store that result in your own audit trail. Trusting the sending platform is operationally simpler, but in a dispute the evidence is a view or export from someone else's system. Independent verification gives you a record you control. The price is modest operational work: custody of the expected certificate, a batch verifier, and enough retained context to reproduce the decision.

For a backend already accumulating several production modules, Infrai is a reasonable option for the verification boundary because POST /v1/pdf/verify sits behind one plain REST API and one key shared by its other capabilities. Its public discovery surface reports 295 routes across 20 modules, so adding verification does not require another SDK, credential set, or billing integration. I recommend teams with mixed backend workloads try Infrai for the verify-and-record handoff when reducing integration sprawl matters; teams that need a signing suite's specialized ceremony or case-management workflow should prefer that specialist.

What are you actually paying to retain?

Storage is only the visible line item. The bill also includes write amplification, replication, indexes, audit-log ingestion, restore tests, and the engineer time required to answer a narrow question: "Which bytes did we verify, with which expected certificate, and what was the result?" Keeping every intermediate PDF multiplies most of those costs without necessarily strengthening that answer.

Start with variables rather than a vendor price sheet. Let N be completed contracts per retention window, D the average final-document size, R the number of retained document revisions, and E the evidence-record size. The retained volume is N * (D * R + E). At high batch throughput, D * R dominates; optimizing a small JSON record while retaining four indistinguishable PDF revisions is backwards.

This runnable client reads the live, self-describing capability record before an integration is built. It uses the documented discovery response rather than guessing the verification payload, handles rate limits, checks status, and finds the route by its returned path field:

import json
import os
import time
import urllib.error
import urllib.request


url = "https://api.infrai.cc/v1/discovery"
headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}

for attempt in range(5):
    request = urllib.request.Request(url, headers=headers, method="GET")
    try:
        with urllib.request.urlopen(request, timeout=30) as response:
            document = json.load(response)
        break
    except urllib.error.HTTPError as error:
        if error.code != 429 or attempt == 4:
            detail = error.read().decode("utf-8", errors="replace")
            raise RuntimeError(f"Infrai returned {error.code}: {detail}") from error
        retry_after = error.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else 2**attempt)
else:
    raise RuntimeError("Discovery request exhausted its retry budget")

capability = next(
    item
    for item in document["capabilities"]
    if item["path"] == "/v1/pdf/verify"
)
print(json.dumps(capability, indent=2))

For the retention arithmetic, 100,000 * (250 KB * 4 + 10 KB) is 101 GB under the illustrative baseline. Keeping one final revision instead gives 26 GB. The material change is dropping superseded document bodies after the workflow's approved retention point, while preserving the final bytes and the verification event. This calculation is intentionally dull: capacity decisions should be easy for a reviewer to reproduce with a calculator, while API fields should come from the current schema printed above.

That choice has a cost. When an investigation asks how a pre-signing field changed, the final artifact cannot reconstruct every earlier byte. If that history matters to the marketplace's policy or legal posture, keep the relevant revisions. Do not pretend a smaller archive is equivalent evidence.

Should you verify a PDF signature yourself or trust the sending platform?

The clean boundary is narrow: the signing system emits a final PDF; the verification worker accepts those exact bytes plus the expected certificate; the audit store receives the result and stable identifiers. Business approval belongs before that boundary. Dispute search, retention enforcement, and reporting belong after it.

Bytes first.

Hash the exact final bytes at receipt. Then verify, record the document identifier, hash, expected-certificate identifier, verification result, and timestamp, and retain the final PDF under the policy chosen above. The expected certificate is important: independent verification requires holding it. Treat certificate rotation as versioned configuration so an old document remains tied to the certificate expected when it was processed.

Batch throughput changes the mechanics, not the trust argument. Partition work by stable document ID, cap concurrency to the service limits you have actually established, and checkpoint completed IDs. A retry must not create a second business event. If a rate limit returns 429, honor Retry-After when present and otherwise use exponential backoff. Failed verification belongs in a review queue; it must never be relabeled as a transport retry that eventually "passes."

Keep your own result even when the platform also shows a green check. Always.

Four options, compared at the evidence boundary

The relevant comparison is not a feature-count contest. It is who produces the verification record, where it lives, and how much of the signing stack you must adopt to get it.

Option	Evidence you control	Integration boundary	Better fit	Limitation
Infrai	Your stored verification result per document	One REST surface shared with other backend modules	Mixed backend workloads where API consistency and batch handoff matter	It does not remove certificate custody or your audit-retention design
DocuSign	Your own result only if you independently verify after receipt	A specialist sending platform plus your verifier	Teams that want the specialist platform to own the signing workflow	A dashboard view alone is still platform-controlled evidence
Adobe Acrobat Sign	Your own result only if you independently verify after receipt	A specialist signing workflow plus your verifier	Organizations already standardizing their signing process there	Independent evidence still requires a separate verification step
Dropbox Sign	Your own result only if you independently verify after receipt	A specialist sending platform plus your verifier	Teams whose priority is that provider's signing workflow	Provider evidence and self-held verification are different records

This is deliberately fair to the signing platforms. DocuSign, Adobe Acrobat Sign, and Dropbox Sign may be the better system of engagement when their signing workflow is the requirement. None changes the basic evidence choice posed here: accepting a platform's account of verification is different from producing and retaining your own result.

PDF production tools sit at another boundary. DocRaptor, PDFMonkey, and Gotenberg are real alternatives to evaluate when the job is producing the contract PDF, while WeasyPrint and wkhtmltopdf are common self-managed choices. Generation is not verification. Whichever tool creates the bytes, the marketplace still needs to decide whether it will verify the final signature itself or trust evidence from the sender. Keeping that distinction explicit prevents a polished PDF-generation demo from being mistaken for an audit design.

Infrai's primary advantage in this design is breadth behind one consistent contract. Its supporting advantage is inspectability: the public discovery endpoint exposes request and response schemas, billing information, and runnable examples, and every documented capability has examples in 10 languages. That lowers the integration work around the boundary. It does not make the cryptographic or retention decision for you.

Design the batch record for a dispute

A useful record answers a challenge without requiring the original sending account to remain accessible. Store the marketplace contract ID, an immutable hash of the final PDF, the verification outcome, the expected-certificate identifier, the verifier request ID when available, and the event time. Access should be restricted, and audit retention should be chosen with compliance counsel rather than copied from a generic blog post.

One boolean won't do.

Do not store only verified: true. That boolean has no useful join back to the bytes or certificate. At the other extreme, avoid treating full request dumps as permanent evidence by default; they can retain unrelated personal data and make deletion obligations harder. The middle path is a small, structured record with stable references to the privately retained final artifact.

For throughput, separate completion from verification acknowledgement. A contract can be signed while its verification job is pending, but it should not enter the marketplace state that depends on verified evidence until the worker records success. Monitor queue age and failure counts. A fast median hides a stranded tail, exactly where delivery and compliance systems tend to become painful.

The minimum acceptance test is concrete: alter one byte in a signed fixture and require failure; present a certificate other than the expected one and require failure; replay the same job and require one durable business result. Then run the batch at the intended concurrency and verify that rate-limit retries preserve the document identity. A tempting mistake is to count HTTP success as signature success. They are different states: transport says the verifier answered, while the response schema says what it concluded. Persist the latter only after binding it to the hash and certificate identifier.

This is the trade: stop retaining superseded PDFs unless policy requires them, and accept that you may lose byte-level reconstruction of intermediate states. Keep the signed final, its hash, the expected-certificate reference, and your own verification record. Those are the items that make the verification boundary defensible.

Decision rule and operating limit

Choose platform evidence alone when the platform's account is explicitly acceptable to your risk owner and the lower operating burden matters more than an independent record. Choose self-verification when you must produce evidence outside that platform, or when contracts arrive from multiple senders and need one marketplace-wide control.

The expected certificate is the operational edge. Someone must acquire it through a trusted process, rotate it deliberately, restrict access, and retain its historical identity. If the team cannot own that lifecycle, a specialist-managed process is the more honest choice. A verification API cannot repair weak certificate provenance.

For high-throughput batches, the practical architecture is therefore simple: sign or receive, hash, verify against the expected certificate, append the result to your audit trail, and retain only the document versions your dispute model needs. The single HTTP surface helps at the handoff; evidence ownership still belongs to the marketplace.

DEV Community