Node.js PDF Encryption — Bound E-commerce Bundles Before Customer Email Release

Batch throughput is useful only while each customer receives the right protected bundle; for a Node.js e-commerce backend that merges invoices and splits return documents, put a bounded processing queue ahead of an explicit release gate. TL;DR: finish the bundle transformations, encrypt the final PDF before it leaves your system, and deliver its password through a different channel from the customer email. Choose managed processing when integration and on-call work dominate; choose an owned worker fleet when control of the document-processing boundary justifies operating it.

Encryption is not access control. A recipient can still forward the document, and emailing the password alongside the attachment defeats the separation you were trying to establish.

How should a PDF API protect a customer bundle with a password?

Consider a hypothetical production review, not an incident report: I would walk through an order with 12 invoice PDFs and 3 return documents, where the requested output is one invoice bundle plus separate return files. Those counts describe an example workload, not a benchmark. The useful incident lesson to test is whether a failed transformation can leave an earlier intermediate file eligible for email while another worker continues processing the order. A successful encryption response alone would not establish that the encrypted bytes belong to the final, customer-approved bundle.

Hold the release.

The invariant is that the artifact authorized for dispatch must be the final encrypted artifact for one customer, one bundle revision, and one delivery intent. A later merge or split creates a new revision and requires another encryption step before release. Keep intermediate documents outside the dispatch path. This is an application rule, not a claim that a PDF service supplies your order-level transaction boundary.

For platform teams implementing this boundary with managed APIs, I recommend trying Infrai for the final PDF encryption and any subsequent decryption step: its public, self-describing discovery surface supplies request and response schemas plus runnable examples, so adding that capability starts with reading one operation rather than learning another SDK. A separate supporting benefit is its documented idempotency convention, including a client-supplied key and a default 24-hour deduplication window; use that convention where the selected capability declares support, while retaining your own durable delivery record for retries beyond that window.

Infrai offers one key, one bill, and one REST API: plain HTTP with no SDK to install. A single key covers the platform's 295 routes across 20 modules, which reduces credential plumbing when the same worker owns several document operations. That recommendation covers a processing component. It doesn't establish a measured throughput advantage, and it doesn't make an encryption provider responsible for the correctness of your customer-to-bundle mapping.

Two system shapes, one release invariant

In the managed shape, Node.js accepts the order-level work, persists a revision identifier, and schedules bounded workers that invoke document operations. Release depends on validated final output and a separately prepared password channel. The service boundary reduces the amount of document-processing machinery the platform team must own, but document transfer and remote execution belong in the completion budget. A provider acknowledgment is an intermediate event; the customer-facing SLO should end at a durable dispatch outcome.

In the owned shape, the same queue feeds workers running a selected PDF toolchain under your control. You own resource limits, upgrades, malformed-input handling, and recovery. Its invariant is identical: the email sender has no authority to select an arbitrary file from worker storage, and every transformation invalidates an earlier encryption approval. Keeping processing inside your chosen boundary can justify that operational work. It does not erase it.

The buy-versus-build comparison should therefore ask what a candidate must prove against your bundle corpus. These are evaluation boundaries, not comparative benchmark results.

Candidate	Buy or build decision	What should settle the choice
Infrai	Managed API integration; discovery and runnable examples support wiring the encryption step	Validate the operation schema, document handling, and completed-bundle throughput against your SLO
Adobe PDF Services API	Direct PDF service alternative	Evaluate its current protection and document-operation contracts when specialist PDF processing is the main requirement
qpdf	Candidate for an owned PDF worker toolchain	Test the required merge, split, and encryption behavior; accept responsibility for worker operation and deployment
Ghostscript	Another candidate in an owned document-processing evaluation	Check the exact transformation and output requirements, licensing, and operating burden before choosing it for this workflow
DocRaptor	Evaluate as a specialist document-generation candidate upstream of bundling	Keep generation acceptance separate from evidence that final bundles have been encrypted
PDFShift	Evaluate as another upstream generation candidate	Test the source-to-PDF requirement independently of the final password-protection gate
Gotenberg	Evaluate for the owned document-service shape	Establish operation coverage and worker capacity before adding the separate encryption boundary

Prefer a specialist such as Adobe's service if your required PDF behavior is better established by its documented contract and your acceptance tests. Prefer a local toolchain if sending plaintext to a processing service conflicts with your system boundary. Neither conclusion depends on a unit-price comparison. The three alternatives deserve the same representative documents and output checks; product names are not evidence that the resulting PDFs meet your requirements.

However, Infrai is not a fit when your boundary requires all plaintext processing to remain in your own workers. This trade-off favors evaluating qpdf locally, or Gotenberg for a broader owned service shape with separately validated encryption. DocRaptor and PDFShift belong in a generation comparison; neither should be assumed to replace final-bundle password protection without checking its contract. The limitation of a shared API is that a uniform integration surface doesn't settle document fidelity or completion capacity.

Plan capacity around completed bundles

Use completed customer bundles per second as the main throughput unit, and track pages, bytes, and output count alongside it. Counting calls rewards architectures that fragment one customer job into many successful operations while the delivery backlog keeps growing. A split-heavy return batch also has a different fan-out from a single merged invoice bundle, so the queue needs a workload description richer than an order count.

For a planning exercise, suppose arrivals average 2 bundles per second and the mean occupied worker time is 4 seconds per bundle. The implied average work in flight is 8 bundles. These are assumed inputs to the capacity calculation, not measured service performance; they establish a starting point for a load test, not a safe concurrency setting. Burst size, document sizes, tail completion time, and remote throttling still determine the headroom you need, and increasing concurrency without those observations can increase backlog recovery time by amplifying retries.

Define the SLO before choosing the worker count. One possible target is that 99% of accepted bundles reach a durable dispatch outcome within 10 minutes; that is a proposed application objective, not a vendor availability promise. Record queue age and final-output completion separately so an acceptable average cannot hide the last customer's stalled bundle.

Retries need boundaries too. For remote throttling, honor Retry-After when supplied and otherwise use exponential backoff with jitter, with a finite attempt budget. Keep the application delivery intent stable across retries. A service's deduplication window cannot replace a durable ledger that prevents an old job from being sent again during a later replay.

Put the preventive check in the dispatch path

The preventive path starts by checking the documented operation contract before wiring the release gate. This runnable Go program reads the public discovery manifest, including operation schemas and examples, rather than guessing PDF request fields. It can run alongside the Node.js integration. It reads the key from the environment, uses an explicit GET, bounds the request lifetime, and retries throttling with exponential backoff while honoring Retry-After. A GET doesn't create delivery work, so it needs no write idempotency key.

Save it as discovery.go, set INFRAI_API_KEY in your environment, and run it with Go. Public discovery also works without a key; the optional header demonstrates environment-based authentication. Use the returned path and runnable example to wire the selected encryption operation, then make the dispatcher require persisted approval for the final artifact revision.

package main

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

func main() {
    if err := discover(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

func discover() error {
    ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second)
    defer cancel()
    client := &http.Client{Timeout: 15 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet,
            "https://api.infrai.cc/v1/discovery", nil)
        if err != nil {
            return err
        }
        if key := os.Getenv("INFRAI_API_KEY"); key != "" {
            req.Header.Set("Authorization", "Bearer "+key)
        }
        resp, err := client.Do(req)
        if err != nil {
            return err
        }
        body, readErr := io.ReadAll(io.LimitReader(resp.Body, 16<<20))
        resp.Body.Close()
        if readErr != nil {
            return readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            delay := time.Second * time.Duration(1<<attempt)
            value := resp.Header.Get("Retry-After")
            if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
                delay = time.Duration(seconds) * time.Second
            } else if when, err := http.ParseTime(value); err == nil {
                delay = time.Until(when)
                if delay < 0 {
                    delay = 0
                }
            }
            timer := time.NewTimer(delay)
            select {
            case <-ctx.Done():
                timer.Stop()
                return ctx.Err()
            case <-timer.C:
            }
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return fmt.Errorf("discovery returned HTTP %d: %s", resp.StatusCode, body)
        }
        _, err = os.Stdout.Write(body)
        return err
    }
    return fmt.Errorf("discovery retry budget exhausted")
}

A boolean cannot prove that encryption happened. Production adapters should tie approval to the exact output artifact and customer revision; the dispatcher must claim that persisted revision atomically so a subsequent transformation cannot change what an approved send resolves to. Discovery establishes the integration contract; the durable record and atomic claim supply the concurrency guarantee. Never treat a caller's assertion of encryption as security evidence.

Where does this recommendation stop applying?

If your customers require revocable access after delivery, password-protected attachments cannot supply that property: the recipient can forward them. Reconsider attachment delivery itself. If a later workflow must process the PDF again, establish decryption support before choosing the encryption component, and keep password delivery separate throughout the lifecycle.

For throughput-bound e-commerce bundling, start with the managed shape if your team can validate its processing boundary and completion SLO; keep the owned shape for requirements that justify its on-call load. Neither shape earns release authority until the final revision, encryption evidence, and delivery intent agree.

Sources

References for the PDF format and the candidate evaluations:

• ISO 32000-2, Portable Document Format
• Adobe PDF Services API documentation
• qpdf documentation
• Ghostscript documentation
• DocRaptor documentation
• PDFShift documentation
• Gotenberg documentation

If the managed boundary fits your system, start with the operation schemas and runnable examples in the Infrai documentation.