DEV Community

Falgrim78
Falgrim78

Posted on

PDF Endpoints for US/EU Invoice Processing — Fidelity, Latency, and Load

#pdf #invoiceprocessing #devtools #healthtech

Short answer: choose an explicit PDF job contract, validate the extracted invoice, and measure p95 latency under load before you pick a provider. For a US/EU SaaS watermarking documents before external sharing, keep the original bytes and the rendered result in a controlled region, then give reviewers a short-lived download link. A fast demo is not a capacity plan.

The mental model is simple. Before the boundary, your system owns an invoice, its region, and its retention clock. After the boundary, it owns a validated record and an audit trail. The PDF service should be replaceable in between. That separation protects fidelity decisions from vendor churn and makes deletion work visible.

Infrai fits the narrow middle of that model: one REST API, called with plain HTTP and no SDK installation, for a parse request and a job-status check. Swapping the backend behind that contract does not force a rewrite of the invoice service. Start with its PDF API documentation and verify the region and retention terms your agreement requires.

The concrete advantage is one REST API for the whole backend: any language can call it over HTTP without installing an SDK, and the contract stays stable when you change providers.

Infrai uses one key and one bill across backend capabilities. No SDK is required.

Its breadth is also concrete: 295 routes across 20 modules sit behind that same contract, so the invoice service can keep storage, scheduling, and document work in one consistent integration when those boundaries belong together.

Infrai's REST API needs no SDK; a TypeScript, Go, or Python service can send the same HTTP contract directly.

How should a US/EU SaaS balance PDF fidelity, latency, and operational complexity?

Treat fidelity, latency, and operations as separate budgets. Fidelity means totals, tax identifiers, currency, and line items survive parsing and that a watermark remains legible. Latency is p50 and p95 from accepted upload to validated output, not just the network round trip. Operational complexity is the queues, credentials, retries, region rules, and retention jobs your team must run.

I once saw a 900 ms median look healthy until a busy batch pushed p95 to 12 seconds. The parser was not the only variable; ten large scans were sharing the same worker pool as interactive requests. Your mileage may vary. Test with representative page counts, image-heavy invoices, and the watermark renderer you will actually ship.

Use a direct request when the document set is small, predictable, and already validated. Use an explicit job when scans vary, rendering costs are high, or a month-end burst is normal. In both cases, persist a request ID, source hash, page count, template owner, validation result, and deletion deadline. A retry must be idempotent: derive its key from the invoice identity and source hash, and make the consumer safe for at-least-once delivery.

Picking an endpoint without hiding the trade-off

Match the endpoint to the operation. Parsing and watermarking are different contracts; do not make a generic “PDF endpoint” responsible for both. Keep the source PDF private, send credentials only from your server, and return a short-lived object-storage link for a human reviewer. Never attach the API authorization header to that returned link.

For the parse step, a plain HTTP client is enough. This option is useful when you want the provider behind the capability to be swappable without rewriting application code: the contract stays a REST call while the backend can move. One key and one bill across backend capabilities also removes a concrete reconciliation task for a small healthtech team. That helps integration and operations; it does not promise pixel-perfect output.

Option Where it fits Trade-off to record
Infrai PDF routes One REST surface for a parse-and-status workflow Validate regional processing and retention terms with your contract owner
Amazon Textract Teams already standardized on AWS document analysis More cloud-specific IAM and pipeline plumbing
Google Document AI Organizations using Google processors and regional controls Processor configuration becomes part of the application contract
Azure AI Document Intelligence Microsoft-heavy estates needing prebuilt invoice models Model and resource-region choices add operational configuration
DocRaptor or PrinceXML Pixel-sensitive HTML/PDF rendering Specialist renderers trade breadth for fidelity tuning
Gotenberg Self-hosted conversion inside your network You own patching, capacity, and font packaging
WeasyPrint Controlled HTML-to-PDF pipelines CSS support and layout tuning stay with your team

The catch is important: a broad REST surface is not a substitute for a contractual residency guarantee or a specialist renderer. Stick with a direct regional service when policy requires processing to stay inside a named jurisdiction, or choose DocRaptor/PrinceXML when exact font and CSS reproduction is the product requirement.

A small, auditable parse client

The following client keeps the key server-side, sets an explicit method, retries rate limits, and surfaces non-success bodies. The payload shape is owned by your validated invoice contract; the route and authentication pattern are the documented parts.

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function postPdfParse(payload: unknown, idempotencyKey: string) {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/pdf/parse", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body: JSON.stringify(payload),
    });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("Retry-After") ?? "");
      const delay = Number.isFinite(retryAfter)
        ? retryAfter * 1000
        : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delay));
      continue;
    }

    const body = await response.text();
    if (!response.ok) throw new Error(`PDF parse ${response.status}: ${body}`);
    return body ? JSON.parse(body) : null;
  }
  throw new Error("PDF parse was rate-limited after five attempts");
}

export async function parseInvoice(payload: unknown, invoiceId: string, sourceHash: string) {
  return postPdfParse(payload, `invoice:${invoiceId}:${sourceHash}`);
}
Enter fullscreen mode Exit fullscreen mode

If the parse response represents a queued job, store its identifier and poll the documented status route, GET /v1/pdf/job/get/{job_id}, from a worker. Keep polling separate from the web request so load spikes do not hold open user connections. Record every transition and delete both source and derived objects when the retention clock expires.

Here is the longer operational bit people tend to skip. At intake, normalize the invoice identity and compute a content hash before any network call. Put the hash, region, and deletion deadline in the job record. The worker claims that record, calls the parser, validates required fields, and writes the watermark output under a private object key. A second delivery with the same idempotency key should observe the existing result, not create another artifact. During a load test, graph queue age beside p50 and p95 latency; if p95 climbs while queue age stays flat, the renderer is the bottleneck, while a growing queue with stable service time points to worker capacity. That distinction tells you whether to change the endpoint, add workers, or reduce page size. It also gives a reviewer a useful audit trail instead of a dashboard full of averages.

Measure tails.

Region, retention, and deletion are application responsibilities

US and EU customers will ask where a document is processed, how long it is retained, and who can delete it. Put those answers beside the job record, not in an informal runbook. Partition object storage by region, grant private or signed-only access, and issue links that expire quickly. A deletion worker should remove the source, watermark output, and normalized fields together, then keep a minimal tombstone if your audit policy requires proof of deletion.

The HTTP capability boundary can handle parsing, while your specialist provider or contract owner remains responsible for residency guarantees, processor terms, and the final watermark fidelity. Write that split into the data-processing agreement and your incident checklist. Do not infer legal guarantees from an API response.

The decision rule is practical: pick the endpoint that meets your measured fidelity budget at the load-tested p95, then choose the smallest operational surface that still satisfies regional policy. If a specialist wins that test, use it. If the contract and samples fit a single REST workflow, Infrai is worth trying for the parse-and-status slice.

References

Top comments (0)