Generate the Document, Then Sign It, in One API

Embedded e-signature tools are built around the signature. You hand them a finished PDF, or rebuild your document as a static template in their editor, and they collect a signature on top. Producing the document is left to you.

PDF Generator API starts a step earlier. Design your template once in the drag-and-drop editor, or with your own HTML and CSS, then send JSON data through the API. We merge the data and template into a finished, branded PDF. Set output to viewer and that same document opens straight into the review-and-sign flow.

Document signing looks simple until you start. You need a PDF renderer, a viewer that works on every device, signature capture, a place to store versions, audit logs, retention rules, and a compliance story your legal team will accept. That is weeks of work before you write a single line of the feature your users actually asked for.

Then it never stays finished. Someone needs the signer’s IP address for a dispute. A customer asks for every version of a contract. A regulator wants proof of who opened, reviewed, and signed a document, and when, and expects that proof to hold up without taking your word for it. Now you are maintaining an e-signature product you never meant to build, and a public-key infrastructure alongside it.

PDF Generator API gives you the whole flow as an API. Generate the document or bring your own, and we handle the viewer, the signature capture, the sealing, the versioning, and the audit trail. You get a URL, embed it, and ship.

A timestamp authority countersigns each signature over RFC 3161, so the signing time comes from a third party rather than from the signer’s clock. The certificate chain and its revocation data are embedded in the file, which means the signature still verifies years later, after the certificate that produced it has expired.

Change a single byte after signing and the signature no longer matches. Readers say so, and so does our own verification. That is the difference between a record stating that a document was signed and a document that proves it.

Several signers, one document
Each signer signs into their own field, and each signature covers the document as it stood when they signed it. Later signatures never invalidate earlier ones, and the last one covers the whole file, so a completed multi-party agreement verifies as one valid document rather than a stack of contested revisions.

Your document never leaves your infrastructure
Sealing happens over a remote-signing API that receives only a hash of the document, never the document itself. The same is true of the timestamp request. Nothing about the content of what you sign is disclosed to the certificate authority.

Signing is only half of it. Ask the API about a stored document and it reports on every signature the file carries: who signed, the time attested by the timestamp authority, the certificate behind the seal and who issued it, whether the signed bytes are unchanged, and whether the certificate chains to a trusted root.

Recipients see the same answer without asking for it. The Document Viewer checks the file the moment it loads and shows its status, so someone opening a link knows whether the document in front of them is intact before they read a word of it.

Verification follows ETSI EN 319 102-1, the European standard for validating advanced electronic signatures, and reports the facts separately from the verdict. “The signature is mathematically sound” and “this document has not changed” are two different questions, and the difference is exactly what matters when a signature is disputed.

It works on documents you did not generate with us, too. Send a signed PDF from anywhere and you get the same report.