What is a signing envelope?

A signing envelope is the unit of work in electronic signature software. It is not “the PDF.” It is the envelope around one file: a title, field marks, one or more recipients, tokenized signing links, a status, and an audit trail. You prepare it, send it, and file the stamped copy when everyone finishes — or you void, correct, expire, or record a decline on that same id.

The desk, the public API, bulk send, and a Web Form fill all create that same envelope. If you already know the click-path, use the five-minute send. If you want the category map, start with what electronic signature software is. This guide is the envelope itself: what it holds, how it moves, and which tool should start it.

What an envelope holds

Open a document on the desk and you are looking at one envelope. Other workspaces cannot see it. Roles stay ordinary: owners create the workspace, admins invite, members send.

• The PDF — stored behind an S3-compatible interface, or Local fallback when S3_* keys are missing. Empty files, non-PDFs, and unreadable bytes are rejected on upload.
• Field marks — signature, date, text, initials, checkbox, and select, stored as page percentages and assigned to recipient slots.
• Recipients — up to 20 on one envelope. Sequential or parallel routing decides who is invited when.
• Send options — reminder interval, expiration, optional access code, optional SMS when a phone is stored.
• Status and audit — created, sent, viewed, signed, completed, and, when they happen, declined, voided, corrected, expired.

Place marks on the draft. Once the envelope is sent, fields and routing are locked. After completion, pdf-lib stamps values onto a second stored object. That stamped PDF is the filed copy. The trail explains how you got there — how to read an audit trail and what a completed envelope includes.

The envelope is not the file

Anyone can email a PDF and ask for a scan back. An envelope binds the mark to a named recipient, a token, and a time. Viewed is not signed. Signed on a multi-signer envelope is not completed. Completed cannot be voided. Those distinctions are why ops teams stop forwarding “final_final_v3.pdf” and start sending a link.

How an envelope moves

Every send follows the same loop, whether you clicked the desk, started a bulk job, published a slug, or POSTed from a worker.

1. Created — a draft exists. Fields and recipients can still change. Nothing has been invited.
2. Sent — a signing link was issued. If Resend is missing, the invite was logged and the desk still shows the URL.
3. Viewed — someone opened the token (and passed an access code if you set one).
4. Signed — that signer submitted required marks. Others on the same envelope may still owe a mark.
5. Completed — every signer finished. Download the stamped PDF from the same envelope.

A signer can decline with a reason. You can void an in-flight envelope. You can correct an outstanding recipient. The window can expire. Those closes stay on the same envelope id so webhooks and the document list do not grow twins. Envelope admin is that toolkit.

Who starts the envelope

Pick the start that matches who already has the recipient list. Do not invent a second factory.

• One-off PDF in front of a person — upload on the desk. Five-minute send.
• Same layout, known emails — template plus bulk send, or the public API if a system already owns the list.
• Strangers should start themselves — publish a Web Form at /form/SLUG.
• Several people on one agreement — one envelope with routing, not a bulk job. Send one envelope to multiple signers.

Bulk send vs Web Forms and API vs desk for ops teams are the forks if you are still choosing. A Web Form fill is still one envelope. A bulk row is still one envelope. An API create-from-template is still one envelope. The monthly envelope cap counts those sends, not the number of signature boxes.

Caps the envelope shares

Send, bulk send, Web Form fills, and POST /api/v1/packets/:id/send share one monthly envelope cap. Free allows 5 packets a month. Hitting the cap returns HTTP 402 and code ENVELOPE_LIMIT. Free at 5 packets a month is the live send cap. Starter is 20 envelopes — more than Free — plus 3 published Web Forms. Seat counts on Pricing are planning numbers; invite does not refuse when a workspace is full. Billing is published, not charging. Checkout is not open.

What the signer sees

The signer opens a tokenized URL. They do not create an Inkpacket account. If you set an access code, they enter it first — share that PIN on a second channel; it is not in the invite email. After five incorrect tries the page locks for 15 minutes. If the envelope expired, they see This signing link has expired. If you voided it, the link dies. If they will not sign, they decline with a reason and the whole envelope closes.

Embedded signing uses the same token. You iframe /embed/sign/TOKEN or the invite URL at /sign/TOKEN. The iframe posts viewed, signed, and completed to the parent. That is UI, not the legal record. Embedded signing and the embed snippet live on those pages.

Honest edges on the same envelope

Mail, SMS, Drive, and card collection do not pretend to succeed without keys. Resend missing: copy the link. Text-message (SMS) is coming soon. Drive missing: Drive not configured. Stripe off: Payments not live. The envelope still exists. FAQ uses those same phrases.

Electronic signatures here are simple, not qualified. Inkpacket does not ship notary workflows, knowledge-based authentication, or qualified electronic signatures. Suggest starting layout is a page-count heuristic, not a model that reads the PDF. Those limits keep the desk a PDF, fields, a link, a signature, an audit, and a download.

A signing envelope is the thing you operate on a Tuesday: prepare, send, file, recover when the address was wrong. Open a workspace on Free — signup or sign in — send one envelope, and read the events on that envelope when someone asks what happened.