What is an envelope in e-signature software?

One document, not a folder

The envelope metaphor breaks in one place: a paper envelope can hold a bundle, while here one envelope carries one PDF. Sending three agreements to the same person means three envelopes, each with its own recipients, fields, status and finished file. That constraint is worth knowing when quoting, because pricing and reporting are usually counted per envelope, and it shapes how bundles are handled. Where several documents genuinely form one transaction, the usual approach is to combine them into a single PDF before sending, so the signer works through one continuous file and receives one completed copy.

Recipients, fields and the link between them

Every field belongs to exactly one recipient, which is what lets the portal show each person only their own boxes. Up to twenty five recipients can be added and up to five hundred fields placed, with colours cycling through five values by list position so overlapping fields stay legible while preparing. Ten field types exist, and five of them are filled by the signer: signature, initials, date signed, name and the signature block. Before an envelope can be sent, every recipient who is not a copy recipient needs at least one signature, initials or block field, since a date field alone would leave nothing to sign.

Why sending is a one way door

Once an envelope leaves draft, the editor closes and the status page takes over. That is not a missing feature. A document whose contents or routing can change after somebody signed is worth very little as evidence, because the version a signer saw could differ from the version now held. The same reasoning explains why a rotated or password protected PDF is rejected at upload rather than repaired quietly, and why the upload has a size ceiling of twenty five megabytes. Corrections after sending mean voiding the envelope and sending a fresh one, which leaves both records intact.

The clock every envelope carries

Each envelope expires thirty days after it is created, and that period is fixed: no screen offers a different date. Recipient links inherit that expiry when invitations go out, so a link cannot outlive its envelope. A nightly sweep moves outstanding recipients and the envelope itself to expired and records the event. After that, opening the link returns a plain message rather than a signing page. Where a document needs longer, the answer is to send a new envelope rather than to extend an old one, which keeps the audit record of each attempt separate and readable.

What the envelope produces at the end

Completion generates more than a signed PDF. The document is stamped for each signer in turn, then sealed with a PAdES signature certified at DocMDP level one so later edits are detectable. A certificate of completion is written as its own file with ENVELOPE, SIGNERS and EVENT LOG sections, and it can optionally be appended to the document itself, in which case the append happens before certification. Everyone who was on the envelope, plus the sender, receives the completed copy by email. The event history behind all of it lives in the audit trail, which has its own page in this glossary.

Where envelopes come from besides an upload

Three sources exist: a direct upload, a document written in the documents module, and a form response carrying an e-signature component. The two handovers stage the rendered PDF internally rather than sending it across a public interface, and both create recipients automatically from what the source document contains. A document's signature blocks become one recipient each, with the block's lines mapped to name, title, company and date fields. A form creates one envelope per submitted response. In both cases the envelope that results behaves exactly like an uploaded one from that point onward, with the same statuses, the same expiry and the same finished artefacts at the end. The source is recorded on the envelope, so where a document came from stays visible later.

Questions people ask