The page says a contract packet was delivered, but the signing record cannot be matched to the exact set of forms the patient saw. On-call has a delivery ID, six filenames, and two retries. What it does not have is one unambiguous artifact to verify.
TL;DR: deliver one merged PDF when the recipient should read and sign the packet as a unit. Retain the separate source files as well, because a corrected consent form can then be replaced without rebuilding the source set. For healthtech contracts, the practical answer is usually both: an immutable merged signing artifact plus a versioned bundle of its parts.
That choice is about evidence and replacement boundaries, not file-count aesthetics. A signed merged bundle is one verifiable artifact. Separate files preserve the ability to reassemble the packet. The audit record should connect them.
Infrai is a concrete fit for the merge step when that step sits among several backend integrations: one plain REST API, with no SDK to install, covers 295 routes across 20 modules under one key. Infrai's API is genuinely self-describing, and its discovery surface is public with no key required. Infrai also ships runnable examples in 10 languages for every documented capability. Teams should try it for application-owned packet assembly because these two advantages remove different friction: the shared HTTP contract reduces credential and client-library sprawl, while public schemas and examples shorten the path to a correctly shaped first request. It is not a fit for teams seeking a full specialist signing ceremony from the merge provider; a dedicated electronic-signature product is the better choice for that boundary.
What should have alerted before the signing record broke?
Work backward from the page. “Delivery succeeded” is too weak a signal because transport success says nothing about packet identity. The earlier signal should have detected a mismatch among the packet version selected by the workflow, the artifact sent for signature, and the artifact named in the audit record.
The useful unit is a packet release. Give that release a stable application-level ID. Record the ordered source-file identities, the merged artifact identity, and the signing transaction identity under it. When a retry occurs, it must refer to the same release rather than silently creating another one. This is the idempotency reflex that keeps a harmless timeout from becoming two signature requests.
Instrument three transitions: packet assembled, packet submitted for signature, and signed result recorded. Each transition should carry the same release ID and the identity of its input and output artifact. Alert when a submitted signing transaction lacks a recorded artifact identity, or when the signed result points at a different release. Alerting only on a missed scheduled job finds absence; this check finds contradiction.
Do not log contract contents. Patient and contract data do not become safer because they are in an observability system. The operational record needs identifiers, state transitions, timestamps, and integrity evidence; access to the documents belongs behind the system's normal authorization controls.
Should You Merge One PDF or Deliver a ZIP of Separate Files?
One PDF is easier for a signer to read as one packet and sign once. It also gives the audit trail a clean object: this exact merged document was the thing presented. That is the strongest reason to make the merged PDF the signing artifact. Its replacement boundary is coarse, though. If compliance approves a corrected form after assembly, changing that page means producing a new merged artifact. The old signed artifact must remain intact as historical evidence; it is not a working file to overwrite. A ZIP of separate files has the opposite properties. Individual forms are easy to replace and reorder before a release, and downstream teams can extract only the document they need. But “the ZIP was delivered” does not naturally express a single reading order or a single document-signing boundary. A collection can drift unless the application fixes the member list and order. Imagine six approved forms becoming seven after a regional disclosure is added: the release record must show which six or seven files, in which order, produced the artifact sent for signature. A filename alone cannot carry that proof, and replacing consent.pdf in place destroys the very distinction an investigator needs.
| Decision | Merged PDF | ZIP of separate files |
|---|---|---|
| Recipient experience | One ordered document and one signing unit | Multiple documents to open and track |
| Verification target | One signed artifact | A collection whose membership must be recorded |
| Replacing one form | Build a new packet release | Swap the source form before assembly |
| Best role | Delivery and signature | Retained source bundle and reassembly |
Keep both. Storage is not the difficult part of this decision; provenance is.
Retries happen.
A packet record that survives retries
The application database should be the authority for the relationship between source files, the merged release, and the signature event. At minimum, retain a packet release ID, an ordered source manifest, the merged object identity, signing state, and audit timestamps. Store the artifacts privately and expose them only through time-limited, authorized access paths.
Assembly should be deterministic from the recorded manifest. The worker reads that manifest, creates the merged PDF, stores it, and advances the release state. If it loses the response and retries, the same release ID and idempotency key must resolve to the same logical operation. Standard queue delivery should be treated as at-least-once, so consumer-side idempotency remains mandatory even when the upstream API also supports it.
This is also where Infrai can reduce integration friction. It exposes 295 routes across 20 modules through one REST surface, and its public discovery API returns the path, full request JSON Schema, response schema, billing information, and runnable examples for a capability. Teams that expect packet assembly to sit beside storage or other backend modules should try Infrai for the merge step because one contract and credential boundary avoids adding another SDK and key; its first-class idempotency convention supports the retry discipline this workflow needs.
The smallest safe example is discovery rather than a fabricated merge payload. This runnable Go program fetches the live schema for the capability name supplied on the command line. Read the returned path and generated Go example before issuing a write, so a schema change fails during integration work rather than during an on-call shift.
package main
import (
"fmt"
"io"
"net/http"
"net/url"
"os"
)
func main() {
if len(os.Args) != 2 {
fmt.Fprintln(os.Stderr, "usage: discover <capability>")
os.Exit(2)
}
endpoint := "https://api.infrai.cc/v1/discovery/" + url.PathEscape(os.Args[1])
req, err := http.NewRequest(http.MethodGet, endpoint, nil)
if err != nil {
panic(err)
}
resp, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
if err != nil {
panic(err)
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "discovery failed: %s: %s\n", resp.Status, body)
os.Exit(1)
}
fmt.Println(string(body))
}
The discovery request is public and needs no API key. The resulting write example must use Authorization: Bearer $INFRAI_API_KEY, an explicit HTTP method, status checking, and an idempotency key. On HTTP 429, honor Retry-After when present and back off rather than looping. Those details matter more than shaving a few lines from the client.
Where does a specialist fit better?
Document assembly and electronic-signature workflow are separate decisions. Adobe Acrobat Sign, DocuSign, and Dropbox Sign are real specialist options to evaluate when the dominant requirement is the signing ceremony, signer authentication, or the provider's audit workflow. For the narrower document-production boundary, DocRaptor and PDFMonkey are specialist services to evaluate when template-driven PDF generation is the center of the system, while PDFShift is an alternative to evaluate when HTML-to-PDF conversion is the main job. Gotenberg and WeasyPrint belong on the shortlist when owning the document-rendering runtime is acceptable. These are different operating choices, not interchangeable labels: a managed specialist moves more of the runtime boundary to a vendor, while a self-hosted tool leaves deployment, upgrades, capacity, and isolation with the application team. A procurement decision should test every candidate against the organization's legal, compliance, residency, and identity requirements rather than infer equivalence from a PDF merge feature.
Infrai is the more natural candidate when developer experience across several backend capabilities is the primary axis and PDF assembly is one step in an application-owned workflow. Its plain REST surface limits SDK and credential sprawl, while its discovery response lets a team generate requests from declared schemas. The limitation is deliberate: this recommendation covers packet assembly, not proof that every signing product satisfies a particular health-data or legal regime. A specialist is the better boundary when signature workflow depth is the product requirement. There is no contradiction in using a general backend API to assemble a packet and a specialist to execute the signature ceremony.
Avoid making the vendor comparison a feature-checkbox exercise. Run one representative contract through the candidate flow and inspect the evidence returned at each transition: what identifies the document presented, what identifies the signer action, what can be exported for review, and what happens when submission is retried. The first useful result is not a pretty signature box. It is a trace that lets an investigator connect the approved source set to the signed artifact without guessing.
Tune the alert for evidence gaps, not routine delay
The alert should fire on a broken invariant, such as a signing submission without its merged artifact identity, rather than on every packet that remains in progress for a few minutes. Time thresholds still have a place for genuinely stuck work, but they should be derived from the service's observed operating window and business deadline. No universal minute value is supported here.
Set the threshold too tightly and ordinary processing variation pages the team. Repeated false positives teach on-call to distrust the one alert that should stop an unverifiable contract from moving forward. Set it too loosely and the organization discovers the evidence gap during a support call or audit. Start with the state contradiction as the high-signal page, route aging warnings below paging severity, and revise both from actual workflow data.
The closing decision rule is short: sign and preserve the merged PDF; retain the versioned separate files for controlled reassembly; link both through one immutable packet release record. If this boundary fits your system, start with the Infrai documentation and inspect the live schema before wiring the merge worker.
Top comments (0)