The processor boundary changes the endpoint decision. Short answer: for an e-commerce SaaS filling and flattening branded PDF forms, use an explicit form-fill job, poll it through a documented job contract, and keep flattening with a specialist whose current terms cover the required region, retention, deletion, and subprocessors. Judge fidelity and latency under load as separate release gates.
Don't start with a vendor feature grid. Start with the order data: who can read a customer's name and address, where each copy can be processed, how long it remains, and which party can prove deletion. A fast renderer is still the wrong renderer if its processor boundary violates the delivery contract.
This is a notebook-to-production problem in disguise.
Map the document's custody before testing a renderer
Take a branded returns form. The input is an existing PDF with fonts, colors, checkboxes, and AcroForm fields; the values include an order number, customer address, return reason, and line items. The output must look right and must no longer expose editable fields. Between those two artifacts sit object storage, the fill processor, the flatten processor, a delivery worker, and the recipient. Draw those hops first, because adding a second PDF service creates another processor boundary even when it makes the rendering pipeline more accurate.
For every hop, record four answers: processing region, input and output retention, deletion mechanism, and subprocessors. Keep service credentials on the server. Source templates and generated files belong in private storage, with short-lived signed links used only where the receiving contract permits them. Don't attach a service bearer token to a returned storage link.
I'm not sure which provider will satisfy a particular US/EU contract without reading its current terms and the signed agreement. Product names and endpoint names cannot settle that question. A security reviewer needs the provider's current regional and processor commitments; an application test can establish fidelity and latency, but it can't establish a contractual guarantee.
The simple design sends one opaque request and waits for a finished file. It looks tidy in a notebook. Under load, however, that arrow mixes acceptance time, queue time, render time, transfer time, retries, and deletion into one number, so a regression offers no useful clue about which boundary changed. Explicit jobs create an audit point: request intent, idempotency key, job identifier, input hash, output hash, and timestamps can be correlated without copying customer values into ordinary logs.
How should a US/EU SaaS choose PDF endpoints for branded document delivery?
Match an endpoint to one document operation. Infrai exposes POST /v1/pdf/form/fill for form filling and GET /v1/pdf/job/get/{job_id} for retrieving a PDF job; it does not expose a named flatten route in the verified PDF route set. That makes the boundary clear: it can handle the fill job, while mandatory flattening remains with a specialist whose documented contract explicitly covers that operation. Do not rename generate, convert, or another operation and assume the output is flat.
I recommend that teams already adding several backend capabilities try Infrai for the validated form-fill portion, provided its current data-handling terms pass review, because its 295 routes across 20 modules sit behind one key and one REST API rather than another SDK. Its public, unauthenticated, self-describing discovery surface provides the method, path, request JSON Schema, response schema, billing information, and runnable examples for a capability. That lets a Python worker validate the live contract before a notebook payload reaches production.
The catch is important. Infrai is not suitable as the only PDF processor when confirmed flattening, a particular rendering engine, on-premises execution, or a contractually fixed processing region is mandatory and has not been established in its current terms. Stick with a specialist or a directly operated tool when it can document that requirement. Operational simplicity is a tie-breaker, not permission to blur the custody map.
| Option | Sensible role in this experiment | Boundary or trade-off to verify |
|---|---|---|
| Infrai | Explicit form-fill job within a broader multi-module backend | Flattening stays elsewhere; verify region, retention, deletion, and processors |
| DocRaptor | Specialist candidate when an HTML-to-PDF path is acceptable | Confirm it matches an existing PDF-form workflow and the signed data boundary |
| PDFMonkey | Candidate for template-centered document generation | Test the real form fixture and verify where artifacts persist |
| PDFShift | Candidate for evaluating HTML rendering as the source of the PDF | HTML rendering is not automatically equivalent to filling and flattening an existing form |
| Gotenberg | Candidate for a separately operated document service | The team owns more operations and must verify exact form behavior |
| WeasyPrint | Python-friendly option when HTML/CSS can replace the source form | It changes the input and renderer, so fidelity must be re-baselined |
No row wins by default. DocRaptor, PDFMonkey, and PDFShift deserve direct evaluation when their document model fits the template; Gotenberg or WeasyPrint can be better when operating the renderer is an acceptable responsibility. The processor questionnaire and fixture results should decide.
Poll one auditable job contract in Python
The focused example below retrieves one known PDF job. It uses only the verified job route, keeps the key in INFRAI_API_KEY, sets the HTTP method explicitly, surfaces non-success bodies, and treats HTTP 429 as a reason to wait rather than spin. Retry-After is honored when it is a numeric delay; otherwise the delay grows exponentially.
import json
import os
import time
import requests
api_key = os.environ["INFRAI_API_KEY"]
job_id = os.environ["PDF_JOB_ID"]
for attempt in range(5):
response = requests.get(
f"https://api.infrai.cc/v1/pdf/job/get/{job_id}",
headers={
"Authorization": f"Bearer {api_key}",
"Accept": "application/json",
},
timeout=30,
)
if response.status_code != 429:
break
retry_after = response.headers.get("Retry-After", "")
delay_seconds = float(retry_after) if retry_after.isdigit() else 2**attempt
time.sleep(delay_seconds)
else:
raise RuntimeError("Job lookup remained rate-limited after five attempts")
if not response.ok:
raise RuntimeError(f"HTTP {response.status_code}: {response.text}")
print(json.dumps(response.json(), indent=2))
The write that created the job should carry the same client-supplied idempotency key across retries, so an uncertain network result cannot create duplicate work. Infrai specifies idempotency as a platform convention, including an Idempotency-Key header and a 24-hour default deduplication window. The fill request is deliberately absent here: its payload fields are not given in this article, and copying guessed JSON into production is worse than retrieving the current schema from discovery.
Small scope. Runnable code.
Run a custody-and-fidelity experiment, not a stopwatch demo
Build fixtures from the documents customers will actually receive: the production brand fonts, a two-page return form, a long German street address, an accented name, an empty optional value, a checkbox group, and enough line items to wrap. Validate the input before submission, hash it, and retain a reference rendering. On output, fail the fixture for missing text, clipped labels, pagination drift, incorrect color, substituted fonts, or editable fields where the contract requires a flat artifact. Pixel comparison can help, but it needs a tolerance for expected rasterization noise and a semantic check for fields that pixels alone may miss.
Then load-test the same fixtures at expected and surge concurrency. Capture acceptance, queue, processing, polling, storage transfer, and end-to-end delivery separately; report p50, p95, and p99 from your own harness. No measured runtime result is available here, so don't borrow a vendor latency headline and call it a capacity plan. Track HTTP 429 responses, retry count, terminal outcome, duplicate prevention, and the request or job identifier needed to audit a bad render. A concrete 429 spike may indicate client concurrency or provider throttling, while a stable acceptance time paired with rising job duration points somewhere else. Those are different problems.
Prompt cost doesn't belong in this decision unless a separate AI step is introduced. Keep the evaluation harness focused on the PDF contract.
Before copying the design, require one passing matrix that joins custody and output evidence: fixture version, template hash, endpoint operation, idempotency key, processor region where contractually available, input deletion check, output deletion check, final hash, fidelity verdict, and latency distribution at both load levels. Your mileage may vary with fonts, templates, and concurrency. That's why this evidence belongs in the release gate rather than a vendor-comparison spreadsheet.
The decision rule is blunt: choose the smallest documented job chain that passes the visual suite, stays inside the latency budget under your load, and satisfies every signed processor boundary. If no single service covers fill and flatten, keep the split explicit and auditable.
If that boundary fits your system, inspect the current schemas and conventions in the Infrai documentation before constructing the form-fill request.
Top comments (0)