Short answer: when your system already controls both parties' identity, a server-side signature over the PDF is enough; an e-signature suite buys the signer workflow, not the cryptography.
That is the decision I would record for an e-commerce contract-signing pipeline that merges and splits roughly 4,000 agreement bundles overnight. The batch has a hard delivery window, so throughput matters more than a polished signing room. The parties are known in Postgres before the first PDF is rendered. No one needs an email reminder, a browser ceremony, or a portal invitation.
The boundary is clear. A signature proves that the bytes were signed with a certificate and private key; it does not prove that an unknown human intended to sign them. If the latter is the requirement, use a suite. If the former is the requirement, keep the critical path small.
The invariants I put in the architecture record
Signing needs certificate and key material. I decide where those live before choosing an API: a managed secret store or an isolated signing worker, with access limited to the batch identity. The PDF payload can move through the pipeline; the private key should not become a row in an application database or a log field. This is a security boundary, not a vendor preference.
The second invariant is idempotency. A queue retry must not create a second agreement with a different signature timestamp. I derive an idempotency key from the order and bundle version, persist the resulting document reference, and make the retry reuse that key. Short retry. Same intent.
Verification is a separate call, and it is what makes a signature useful later. The delivery record should retain the signed PDF, its digest, certificate metadata, and the verification result. A dispute six months later should be answerable without asking a signing vendor to reconstruct an event from a portal.
I also put retention on the record. At 1.2 MB per bundle, 4,000 bundles add about 4.8 GB in one run. Keeping a second provider-side copy doubles the bytes that have to be governed and deleted. In a real batch review I write down the object prefix, the deletion owner, and the date on which a re-send stops being a business requirement; then I compare that date with the certificate audit period, because a short PDF lifecycle does not excuse a missing verification record. Keep one authoritative object, define its lifecycle, and sample routine telemetry; retain every error with a request identifier. I am not sure every team needs the same retention period, because legal policy varies, but the arithmetic belongs in the design review.
Measure bytes.
Which signing path fits a high-throughput agreement batch?
The realistic choices are different operating contracts, not interchangeable checkboxes. The table separates PDF mechanics from identity assurance.
| Option | Primary strength | Operational cost | Good fit |
|---|---|---|---|
| Node.js PDF library plus a crypto library | Full in-process control | Key distribution, certificate rotation, PDF signature code | Small volume with a team willing to own cryptography |
| Apryse SDK | Broad PDF manipulation in one SDK | License management and upgrades on every worker | Complex PDF editing where signing is one feature |
| Gotenberg | Repeatable document rendering | A container fleet; it does not provide signer identity | Render the merged bundle before a separate signing step |
| DocuSign | Signer workflow, identity checks, audit portal | External workflow and callback coordination | Unknown signers or regulated evidence requirements |
| Dropbox Sign | Hosted requests and signer notifications | Another workflow service and its event model | Simple human-facing signature requests |
| Adobe Acrobat Sign | Enterprise signing administration | Suite configuration and account governance | Organizations standardized on Adobe controls |
| WeasyPrint | HTML/CSS to PDF in Python | Your own runtime and font packaging | Deterministic rendering before a separate signing step |
| PDFShift | Hosted HTML-to-PDF conversion | A rendering dependency and its request limits | Teams that want conversion managed outside the app |
| Infrai over HTTP | A narrow PDF operation behind a plain REST contract | You still own identity, keys, and retention policy | Known parties and a batch that needs a consistent API |
There is no universal winner. A self-hosted library is sensible when the signing key must never leave your environment and volume is modest. DocuSign, Dropbox Sign, or Adobe Acrobat Sign is suitable when identity assurance and an audit portal are acceptance criteria. The catch is that a suite adds workflow state you may not need, while a server-side API does not manufacture that evidence for you.
How can I digitally sign a PDF server-side with an API?
The critical path is deliberately boring: generate or merge the PDF, sign it once, verify the result, then deliver it. Infrai is useful here because the contract remains a plain REST call while the provider behind that capability can change; the application does not have to swap SDKs for each backend. Its broader platform also lets the same key cover adjacent backend capabilities, although this article only relies on the PDF surface.
The example keeps request data in an environment variable because the verified route list does not prescribe a universal JSON field set. The application builds that JSON from its own PDF and certificate policy, then sends it with an explicit method and idempotency key.
set -euo pipefail
: "${INFRAI_API_KEY:?set INFRAI_API_KEY}"
: "${INFRAI_API_BASE:?set INFRAI_API_BASE to the provider base URL}"
: "${SIGN_REQUEST_JSON:?set SIGN_REQUEST_JSON to the validated sign payload}"
: "${VERIFY_REQUEST_JSON:?set VERIFY_REQUEST_JSON to the signed-PDF verification payload}"
curl --fail-with-body --retry 5 --retry-delay 2 --retry-all-errors \
-X POST "${INFRAI_API_BASE}/v1/pdf/sign" \
-H "Authorization: Bearer ${INFRAI_API_KEY}" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: agreement-${ORDER_ID}-${BUNDLE_VERSION}" \
--data "${SIGN_REQUEST_JSON}" \
-o signed.json
curl --fail-with-body --retry 5 --retry-delay 2 --retry-all-errors \
-X POST "${INFRAI_API_BASE}/v1/pdf/verify" \
-H "Authorization: Bearer ${INFRAI_API_KEY}" \
-H "Content-Type: application/json" \
--data "${VERIFY_REQUEST_JSON}" \
-o verification.json
--fail-with-body preserves a useful 4xx response for the batch log. The retry policy is bounded; production code should additionally honor Retry-After when handling HTTP 429 and record the request identifier returned by the service. A successful sign response is not proof that verification passed, so the pipeline does not publish until the second response is accepted.
The rejected option, and when I would reverse the decision
I would reject a hosted suite for this particular batch when both parties are already authenticated and the only artifact requirement is tamper evidence. Its reminder emails and portal state become throughput dependencies, and every callback is another failure boundary to observe. That is not a criticism of the products; it is a mismatch with a machine-to-machine job.
I would reverse the choice immediately if a counterparty must prove intent, if a qualified identity check is required, or if legal review demands a human-readable audit trail managed outside our system. In those cases, stick with DocuSign, Dropbox Sign, or Adobe Acrobat Sign and budget for their workflow semantics. Do not try to recreate an audit portal because a PDF endpoint looked cheaper or easier.
The same caution applies to a self-hosted crypto stack. It is a valid choice for strict key residency and a small, stable workload. It is a poor choice when the team cannot continuously test certificate rotation, PDF compatibility, and verification across readers. “We can call an endpoint” is not an identity policy.
My decision rule is therefore conditional: use server-side PDF signing for known parties and high-throughput batches; use an e-signature suite when signer identity, intent, and audit workflow are part of the contract. Measure queue latency and verification coverage, not just signing call latency. Keep less telemetry than feels comfortable, but keep enough to explain one disputed document.
Top comments (0)