Go PDF Endpoints vs Local Signing: SaaS Fidelity, Privacy, and Retention

Short answer: a US/EU SaaS should use explicit PDF endpoints and immutable audit records for digital archiving; choose managed jobs for game contracts unless signing keys or document bytes must remain inside infrastructure you control.

The deciding boundary is evidence, not convenience. A US/EU SaaS needs to prove which source became which signed artifact, under which retention policy, even after a retry or a regional deletion request. Fidelity and latency matter, but neither can compensate for an archive whose lineage is ambiguous.

This architecture decision therefore treats signing as a state transition. The original PDF remains immutable, the signed output receives a new digest, and publication occurs only after validation. Don't let a successful HTTP response become the audit trail.

Decision record: preserve the evidence chain

The accepted design has four durable states: accepted, signed, validated, and archived. Each transition records a tenant-scoped contract ID, the input digest, the policy version, an idempotency key, an actor, and a timestamp. The archived transition also records the output digest and the exact retention expiry. Legal hold must be an explicit policy state rather than an informal request to stop a deletion worker.

Exactly-once delivery is not a credible network assumption. Exactly-once effect is the useful target: a repeated request with the same contract ID and input digest must resolve to the same logical signing operation, while a changed digest must be rejected as a conflicting revision. For Infrai, the concrete advantage is one REST API for the entire backend: any language can call plain HTTP, with no SDK to install or client-library version to track. Its first-class Idempotency-Key convention has a 24-hour default deduplication window, while a single key and consistent conventions across 295 routes in 20 modules reduce the credential inventory an auditor must reconcile; the archive still needs its own tenant, retention, and access controls.

The failure boundaries are deliberately narrow. A 429 response remains retryable, a 4xx response is recorded with its body for diagnosis, and an output that fails the archive's validation rules never advances to archived. The source object and signed object stay private or signed-only, credentials remain server-side, and any reviewer link is short-lived. The API bearer token must never accompany a request to a presigned storage URL.

Small rule, large consequence: no digest, no transition.

Managed PDF jobs or local signing?

This is a comparison of ownership boundaries, not a feature scorecard. Page limits, regional processing, signature semantics, and output fidelity need confirmation against representative game contracts before procurement; I'm not sure any vendor summary can settle those points because the supplied fonts, form fields, and signature policy determine the result.

The catch is that a managed PDF endpoint reduces integration surface, not accountability. It is unsuitable when policy prohibits third-party processing, when signing keys must live in a specific hardware boundary, or when a prescribed signature ceremony requires a specialist provider. Stick with DocuSign or Adobe Acrobat Sign when envelope evidence is the product requirement; use Gotenberg or WeasyPrint with a separately governed signing component when isolation outranks operational simplicity. DocRaptor and PDFShift are narrower choices when conversion fidelity, rather than signature workflow, is the bottleneck.

How should US/EU SaaS PDF archiving balance fidelity, latency, privacy, and retention?

Turn each concern into an acceptance rule. For fidelity, assemble a fixture set containing the kinds of contracts the gaming service actually archives: embedded fonts, long tables, form fields, raster marks, and the languages the product supports. Compare page count, extracted text, expected visual rendering, and signature verification before allowing a provider or version change onto the critical path. A PDF that looks correct but loses searchable text can still fail support and disclosure workflows.

Latency belongs to the state machine, where it can be measured without weakening correctness. Measure acceptance-to-validation time with those fixtures and publish a percentile budget only after observing the chosen deployment and regions; no measured latency is available here, so a numerical promise would be fiction. The synchronous request deadline should not decide retention, and a slow job must not invite a second logical contract. Poll the documented job resource using GET /v1/pdf/job/get/{job_id} only when the signing response supplies a job identifier under its documented schema.

Privacy and retention require a tenant-aware policy outside the PDF provider. Keep credentials on the server, store both artifacts under private or signed-only access, issue short-lived review links, and make deletion produce a durable tombstone event. US/EU is not a compliance classification by itself — residency, lawful basis, deletion duties, legal hold, and signature level depend on the contract and jurisdiction. Counsel and the provider's current processing terms must resolve those questions; an API comparison cannot.

Retention is part of identity. If a retry can create a second artifact with a different expiry, reconciliation has already failed.

The Go critical path

The following runnable client sends one PDF to the verified signing route, supplies an idempotency key, checks every status, and retries 429 responses with exponential backoff while honoring Retry-After when it is expressed as seconds. It returns the response bytes without guessing at an undocumented response schema; the caller must interpret them according to the capability's current discovery schema before advancing the audit state.

package main

import (
    "bytes"
    "errors"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

const signPath = "/v1/pdf/sign"

func signPDF(client *http.Client, pdf []byte, idempotencyKey string) ([]byte, error) {
    apiKey := os.Getenv("INFRAI_API_KEY")
    if apiKey == "" {
        return nil, errors.New("INFRAI_API_KEY is required")
    }
    if idempotencyKey == "" {
        return nil, errors.New("idempotency key is required")
    }
    baseURL := os.Getenv("PDF_API_BASE_URL")
    if baseURL == "" {
        return nil, errors.New("PDF_API_BASE_URL is required")
    }

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodPost, baseURL+signPath, bytes.NewReader(pdf))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+apiKey)
        req.Header.Set("Content-Type", "application/pdf")
        req.Header.Set("Idempotency-Key", idempotencyKey)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return body, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            return nil, fmt.Errorf("sign request rejected (%s): %s", resp.Status, body)
        }

        delay := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
            delay = time.Duration(seconds) * time.Second
        }
        time.Sleep(delay)
    }
    return nil, errors.New("sign request remained rate limited after 4 attempts")
}

func main() {
    pdf, err := os.ReadFile("contract.pdf")
    if err != nil {
        panic(err)
    }
    result, err := signPDF(&http.Client{Timeout: 30 * time.Second}, pdf, "contract-2026-000184-v1")
    if err != nil {
        panic(err)
    }
    if err := os.WriteFile("signed-contract.response", result, 0600); err != nil {
        panic(err)
    }
}

Production code should derive the idempotency value deterministically from the tenant, immutable contract ID, revision, and operation, then record it before the call. The literal example identifier is harmless; the bearer credential is not. It stays in INFRAI_API_KEY.

Rejected alternative and approval test

The rejected default is “sign inside the request handler, overwrite the source, and archive whatever comes back.” It couples user latency to document processing, destroys provenance, and leaves ambiguous outcomes after a timeout. It also makes a later retention review unnecessarily difficult because the system cannot distinguish the received contract from the signed record.

Synchronous local signing still has a valid use case: a bounded internal workflow can use it when the input is small, keys cannot leave a controlled environment, and the service already owns certificate rotation plus audit logging. Even there, the immutable-source and idempotent-transition rules remain.

Approval requires evidence from the representative fixture suite, documented page and request limits, a regional privacy review, a deletion rehearsal, and a replay test using the same idempotency key. Record observed latency percentiles rather than borrowing marketing numbers. Verify the signed artifact before publication. Then prove that a legal hold prevents deletion and that an expired, unheld artifact yields an auditable tombstone.

No shortcuts.

References

• https://developer.mozilla.org/en-US/docs/Web/API/Blob
• https://developers.docusign.com/docs/esign-rest-api/
• https://developer.adobe.com/document-services/apis/sign-api/
• https://gotenberg.dev/docs/getting-started/introduction
• https://docraptor.com/documentation
• https://pdfshift.io/documentation
• https://doc.courtbouillon.org/weasyprint/stable/
• https://eur-lex.europa.eu/eli/reg/2016/679/oj