Document Signing and PDF Sealing

Ordered recipient steps, saved field values and a final seal produced on its own.

This document signing software case study is built around two separate events. One is a recipient finishing their part. The other is the application producing the sealed PDF, and keeping those apart means an unfinished sealing job does not erase work a person already completed.

Senders prepare envelopes from PDFs or from converted Word files. Templates and bulk sending cover the documents that come up again and again.

The challenge

The order of actions matters here. Someone may open a link before their turn, come back after it has expired, or submit a completion request twice. Each request has to be checked against the envelope's current state.

The finished file also has to keep exactly what the recipients submitted, without painting over the original document.

What we built

A sender assigns signers and approvers. Viewers and copy recipients can be added, and then the sender places the fields each person needs. Every signer must have a signature field. Groups can work at the same time, or wait for the group ahead of them to finish.

Recipients usually arrive through a personal link. Extra checks can be switched on for a recipient, such as an account or a password. A passkey or two-factor step can be required as well. The server checks the recipient's role, their order and the expiry before it accepts any input. Failed attempts go into the audit trail. An assistant can fill in fields for another person, yet cannot provide that person's signature.

Technical approach

A completed step runs its update inside a transaction. It moves the status forward only when that step is not already marked done. A repeated submission then comes back with an already-completed result, rather than writing the step a second time.

Field values sit in the database while signing is still going on. Once the required recipients finish, a job renders those values into the PDF. It adds the certificate and audit pages, flattens the file and signs the output with the instance's key. The sealed file is saved as a new record. Resealing always starts from the original, so fields are never drawn twice over a copy that is already done.

A PDF signature lets the finished file be checked for later changes. Recipient identity is recorded on its own through authentication and the audit trail, and the instance's signature does not stand in for those records.

Recovery jobs come back to eligible envelopes that are still pending. Administrators can also see which documents are waiting to be sealed, instead of depending on recipients to resubmit them.

Project success

The sender can follow each participant's progress through the document. Completed actions and pending seals get their own handling, and so do expired links. The original file stays available beside the sealed output and the full recipient history, which gives the process a recovery path after everyone has finished.

Technology stack

Application

TypeScript, React Router, Hono

API

tRPC, OpenAPI

Data access

Prisma, Kysely, PostgreSQL

Document conversion

Gotenberg

Job processing

PostgreSQL-backed jobs, BullMQ or Inngest

Signing

P12 certificates or Google Cloud KMS