After Signing

Downloads & Sealed Documents

Sealed PDF, completion certificate, complete bundle, and SHA-256 hashes. Everything a completed envelope produces.

Every completed envelope produces three primary downloadable artifacts, plus the original:

  • Signed PDF (<title>-signed.pdf): the finalized, flattened document with all signatures baked in.
  • Completion certificate PDF: a separate PDF summarizing the signing event, including the verify URL.
  • Complete bundle: a ZIP containing the signed PDF, the completion certificate, and the audit trail as JSON.
  • Original unsigned PDF: always available for reference and audit purposes.

All four are accessible from the envelope’s detail view in the Desk and via the Partner API.

The signed PDF is the finalized document with all signatures composited into the pixels. Key properties:

  • Flattened. Signatures are baked into the PDF, not stored as separate interactive form fields.
  • SHA-256 hashed. The document’s cryptographic fingerprint is computed and stored.
  • Linearized (via qpdf) for fast web viewing.
  • Encrypted at rest in S3 with AES-256.

This is the primary artifact for legal and record-keeping purposes. If you need one file to represent the completed agreement, this is it.

The completion certificate is a separate PDF that summarizes the signing event as a legal record. It includes:

  • Envelope title and ID
  • List of signers (names, emails) and their sealing timestamps
  • Document SHA-256 hash
  • Sender name and workspace
  • Public verify URL for independent re-verification
  • A redacted timeline of key audit events (viewed, signed, IP)

The certificate is a standalone document, meaning it can be filed separately from the signed PDF for compliance or audit purposes.

The complete bundle is a ZIP file that packages everything an auditor might want in one download:

  • document-signed.pdf: the sealed document
  • completion-certificate.pdf: the certificate
  • audit-trail.json: the full append-only audit log for the envelope (viewed events, signed events, IPs, timestamps, user agents)

The JSON audit trail includes every event tied to the envelope, not just the summary shown on the certificate. This is the most complete package signID provides for a single envelope.

Tip. If you’re preparing for legal review or an audit, the complete bundle is what you want to hand over. It has both the human-readable PDFs and the machine-verifiable JSON.

The original PDF the sender uploaded remains available for the life of the envelope, before signing, during, and after. Signers download it via the signing UI; senders download it via the envelope detail view.

Why keep the original?

  • Signers can review the document they agreed to (with static sender elements composited but no signature graphics yet)
  • Version comparison against the signed PDF is possible
  • If a “Replace unsigned PDF” happened before signing, version history preserves both

Every sealed PDF has a SHA-256 hash computed at seal time. This hash is a 64-character hexadecimal fingerprint that changes if even one byte of the PDF changes.

How you use it:

  • The hash appears on the completion certificate, the sealed-receipt email, and the public verify page.
  • To verify a PDF is untampered, compute its SHA-256 (any file utility can do this) and compare to the recorded hash.
  • If they match, the PDF is byte-identical to what signID sealed. If they don’t, the file was modified after signing.
# macOS / Linux
shasum -a 256 document-signed.pdf

# Windows (PowerShell)
Get-FileHash -Algorithm SHA256 document-signed.pdf

When an envelope reaches signed status, everyone involved receives a sealed-receipt email:

  • The sender (owner)
  • Every signer on the envelope
  • Any additional CC’d parties configured on the envelope

The email contains:

  • A brief summary of the signing event
  • The sealed PDF attached (or a download link if too large)
  • A public verify URL for independent verification
  • The document SHA-256 hash

Emails use your workspace’s white-label branding (see White-Label & Branding).

For large envelopes, sealing is asynchronous. The completion screen shows a brief pending state for the download buttons while the background worker assembles the sealed PDF and computes its hash.

What you’ll see:

  • A spinner or “Preparing sealed document…” message on download buttons
  • The signer’s confirmation and completion timestamp are already recorded, only the artifact is being generated
  • Once ready (usually within seconds), buttons activate automatically, no page refresh needed
Note. If you close the tab during finalization, that’s fine. The download will be waiting for you (and for every recipient) the next time anyone opens the envelope, or via the sealed-receipt email.

Signers automatically get a copy of the sealed document via the sealed-receipt email. In addition, they can access it anytime via:

  • The completion screen (immediately after finishing)
  • The signer portal at /my-documents (with email OTP sign-in)
  • The original signing link (still resolves to a sealed-document view once completed)

This means signers never need to keep the email around, they can always retrieve their copy later.

Ready to send your first envelope?

Create a free signID account, or book a demo to see how it fits your team or platform.

Back to Knowledge Base