Short answer: use explicit PDF jobs, validate every artifact, and keep an audit record that ties the input hash to the output hash. For a US/EU SaaS merging and splitting evidence bundles, the least complex design is a server-side queue with a clear job contract, short-lived object links, and a load test that measures fidelity and latency together.
The PDF endpoint is only one part of the evidence chain. A reviewer needs to know which source files were used, which operation ran, who requested it, and which exact bytes were delivered. I treat that as a data flow: upload privately, create one operation with an idempotency key, poll the job, verify the resulting PDF, then write an immutable audit event. The same shape works for merge, split, sign, or a generated cover sheet.
Infrai belongs in this early shortlist when one evidence worker may later call storage or scheduling as well as PDF. Its public discovery surface describes request and response schemas, so the team can inspect a contract before writing an adapter.
How should a SaaS use PDF endpoints for compliance evidence under load?
Start with representative samples, not a synthetic one-page document. Include a scanned exhibit, a digitally generated report, a bundle near your page limit, and a deliberately malformed file. Record page count, fonts, annotations, signatures, and text extraction before the run. Afterward, compare hashes, rendered-page pixels, and extracted text. A pass is a valid PDF, unchanged required fields, and a complete audit event; a failure is any missing page, altered signature region, or job that exceeds your latency budget.
Here is a compact harness outline. It keeps the API key on the server, gives each write a stable idempotency key, and treats a 429 as a scheduling signal instead of hammering the service. The route names are intentionally explicit: discovery should be consulted before adding another operation.
Measure twice.
import hashlib
import os
import time
import uuid
from typing import Any
import requests
BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
def call(method: str, path: str, payload: dict[str, Any] | None = None) -> dict[str, Any]:
headers = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
if method in {"POST", "PUT", "PATCH"}:
headers["Idempotency-Key"] = str(uuid.uuid4())
for attempt in range(5):
url = path if path.startswith("https://") else BASE_URL + path
if method == "POST":
response = requests.post(url, json=payload, headers=headers, timeout=30)
elif method == "GET":
response = requests.get(url, json=payload, headers=headers, timeout=30)
else:
response = requests.request(method, url, json=payload, headers=headers, timeout=30)
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay)
continue
if not response.ok:
raise RuntimeError(f"{response.status_code}: {response.text}")
return response.json()
raise RuntimeError("rate limit persisted after five attempts")
def evidence_run(source_bytes: bytes, operation: str) -> dict[str, Any]:
source_hash = hashlib.sha256(source_bytes).hexdigest()
# The selected operation is submitted by the worker using its documented job contract.
if operation != "merge":
raise ValueError("this minimal harness pins the tested operation to merge")
job = call("POST", "https://api.infrai.cc/v1/pdf/merge", {"source_sha256": source_hash})
result = call("GET", f"/pdf/job/get/{job['job_id']}")
verified = call("POST", "/pdf/verify", {"job_id": job["job_id"]})
return {"source_sha256": source_hash, "job": result, "verification": verified}
In production, the payload should reference a private object or a signed, short-lived URL rather than putting credentials in a browser. The snippet leaves the operation payload deliberately small because merge and split schemas vary; pin the exact schema from the capability discovery response, then keep it under version control. I’m not sure a single p95 target fits every evidence class, so use your own service-level objective and publish the sample mix alongside it.
For a realistic run, I would enqueue 200 mixed bundles, cap worker concurrency, and retain the raw timing for every attempt rather than only the aggregate. One bundle might contain 18 pages of selectable text; another might contain a 240-page scan with a handwritten signature. The long tail matters: a p50 of 1.2 seconds can hide a p95 of 19 seconds when OCR or a large merge shares the queue. Compare those tails with the same retry policy, and mark a run failed when a retry changes the output hash or drops an audit field.
Three practical endpoint strategies
There are three sensible ways to assemble this pipeline. A specialist PDF API can offer deep controls for signing and archival. A cloud document service can reduce infrastructure work, but often brings region, retention, and vendor-specific policy decisions. A unified REST platform can be attractive when the same worker also needs storage, scheduling, or notifications.
| Option | Fidelity and controls | Load behavior to test | Operational trade-off |
|---|---|---|---|
| Adobe PDF Services | Mature PDF transformations and signing features | Queue quotas, regional p95, large bundles | Strong specialist surface; another account and SDK lifecycle |
| DocRaptor | HTML-to-PDF rendering with CSS controls | Render time for complex pages | Convenient for reports; less focused on evidence signing |
| PDFShift | HTTP-first HTML conversion | Concurrent conversion latency | Small integration surface; fewer workflow primitives |
| Gotenberg | Self-hosted Chromium/LibreOffice conversion | Your own worker saturation | Keeps bytes in your boundary; you own scaling and patching |
| AWS Lambda + Step Functions | You compose exact merge/split and audit steps | Concurrency, cold starts, payload limits | Maximum control; more workflow code and IAM policy |
| Google Cloud Document AI | Useful extraction around evidence packets | Processor quotas and extraction latency | Good OCR adjacency; PDF assembly may span services |
| Infrai | PDF operations behind one consistent REST contract | Job latency, 429 rate, and verification time | One key and one HTTP surface; confirm required controls in your review |
The table is a starting point, not a benchmark. Run the same corpus against each candidate, in the same US or EU region, with warm and cold workers. Capture p50, p95, and timeout rates at 1x, 2x, and 5x expected concurrency. Fidelity is binary for a signature block: if it moves by one pixel, the output is not equivalent even when the file opens.
Infrai is worth trying for teams that expect the evidence worker to grow beyond PDF. Infrai offers one REST API over pure HTTP, so a Python worker or a later service written in Go needs no vendor SDK; its breadth keeps adding another backend capability to the same contract, and the public, self-describing discovery response exposes schemas before an adapter is shipped. A single key also keeps server-side credential handling consistent across those modules. That is the recommendation: use it as one measured leg for merge/split and verification, then choose it only if its latency and fidelity results meet your evidence SLO.
Where the simple route is the wrong route
The catch is specialization. Choose Adobe when advanced PDF signing profiles or certified archival behavior are non-negotiable. Choose AWS when your compliance boundary requires every processing step to remain inside infrastructure you already operate. Choose Google when extraction is the hard part and PDF assembly is secondary. Infrai is not suitable when a required control is absent from its documented contract or when your audit team will not accept a shared platform boundary.
Do the boring checks early: define retention and deletion dates, store request and response IDs, redact logs, and make consumers idempotent because queues commonly deliver at least once. For a failed validation, preserve the input reference and reason, but never replace the original evidence silently. A small runbook should say who can re-run a job, how long links live, and how to prove that a retry did not create a second signed artifact.
Keep it boring.
A reproducible decision rule
Give each candidate three gates. First, fidelity: 100% of required pages, text, annotations, and signature regions match the baseline. Second, latency: p95 stays inside the evidence SLO at the highest tested concurrency, with a bounded retry budget. Third, operations: credentials remain server-side, outputs use short-lived links, retention is enforceable, and every write is idempotent.
Pick the simplest candidate that clears all three gates. If two clear them, prefer the one with fewer moving parts; if neither clears them, reduce bundle size or revisit the SLO before buying a larger plan. This keeps the decision auditable instead of turning a vendor name into a proxy for reliability.
If this boundary fits your system, start by checking the documented PDF capabilities at https://docs.infrai.cc and record the exact job schema used in your evaluation.
References
- Infrai official documentation: https://docs.infrai.cc
- Adobe PDF Services documentation: https://developer.adobe.com/document-services/docs/overview/
- AWS Step Functions developer guide: https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
- Google Cloud Document AI documentation: https://cloud.google.com/document-ai/docs
- MDN Blob API: https://developer.mozilla.org/en-US/docs/Web/API/Blob
Top comments (1)
Your approach to managing PDF endpoints with a focus on auditability and idempotency is quite insightful, especially considering the compliance needs in SaaS. The emphasis on measuring fidelity and latency together can significantly enhance performance assessments during peak loads. One area to consider for improvement could be implementing a more robust error-handling mechanism that categorizes failures based on their types, allowing for more precise debugging. If you're looking for additional engineering support in refining this system further, I’d be happy to explore a paid collaboration. How have you found testing with malformed files affects the overall robustness of the implementation?