Creating Envelopes

An envelope is signID’s unit of a signing request: one PDF, its fields, its recipients, its metadata, and its audit trail, all tracked together. Envelopes move through a small set of statuses:

1. Draft. You’ve uploaded the PDF and are placing fields. No links have been issued.
2. Pending. You’ve sent it. Signer links exist and are active. Recipients complete their fields on their side.
3. Signed. All signers have finished. The sealed PDF is generated (sometimes asynchronously for large files).
4. Terminal. Beyond signed, envelopes can end up declined, expired, or cancelled.

Once terminal, an envelope’s state doesn’t change, but its downloadable artifacts (the signed PDF, the completion certificate, the complete bundle) remain available in your workspace forever, subject to your data retention preferences.

From the Desk, click New Envelope. Drag your PDF into the upload zone, or click Browse to select one. Only PDF is supported as the source format.

What if your document is in another format?

• Word / Google Docs / Pages: use File → Export as PDF (or Print → Save as PDF) first.
• Multiple pages / images: combine into a single PDF using any PDF tool, then upload.
• Scanned or image-only PDFs: work fine, though you cannot place fields on top of specific text (fields are absolute-positioned, not text-anchored).

For files above a size threshold, signID switches to a direct-to-S3 upload path. Instead of streaming through the API server, the browser gets a presigned URL and uploads chunks directly to storage.

Why this matters:

• Uploads finish much faster on large files.
• The API server never handles the raw bytes, so upload speed doesn’t depend on API server load.
• You can upload files up to the platform ceiling (targeting ~2 GiB / 10,000 pages).

The upload UI shows a progress bar. If your connection drops mid-upload, resume support handles it. Just start the upload again and the client will pick up where it left off.

Once your PDF is uploaded, you land in the field editor. Layout:

• Left rail: palette of signer fields and sender elements. Collapsible if you need more canvas space.
• Center: your PDF pages, scrollable. Drop fields anywhere.
• Right rail: field properties (assigned recipient, required flag, size, label).
• Bottom bar: zoom, page navigation, Preview, Save, Send.

The editor autosaves every change with a short debounce (typically a second or two). You won’t lose work if you close the tab. Field coordinates are stored in PDF points, so placement is resolution-independent, meaning the field lands in the same visual spot whether the signer’s on a phone, tablet, or desktop.

You can drag to reposition, drag edges to resize, and delete with the keyboard or the right-click menu.

signID has 7 signer field types, the interactive blocks a recipient fills:

• signature. The recipient draws or types their signature. This is the anchor field for most envelopes.
• date. A date, typically the signing date, auto-populated but editable.
• initials. Compact initials block. Often placed on every page of a long contract.
• name. Free-text name field. Pre-fills with the recipient’s known name and is editable.
• text. Any free-text input. Useful for addresses, order numbers, notes.
• checkbox. A single checkbox the signer toggles.
• radio. A radio group for one-of-many selection.

Every field is assigned to a specific recipient. If you have two signers, you specify who is expected to fill which fields.

In addition to signer fields, senders can add static elements, content that isn’t interactive but gets composited into the PDF at send time. Available element types:

• Text block, address block, company name, title
• Date stamp, page number, initial marker, check mark
• Attachment marker, read-only field, hyperlink
• Image, QR code
• Divider, highlight, whiteout
• Internal-only notes and sender-only signature previews (never delivered to signers)

Static elements are flattened into the PDF at send time, meaning they become part of the pixels the signer sees. They cannot be interacted with, only viewed. This is intentional: the sender sees what they place, and the signer sees exactly the same thing at Send time.

In the field editor, open the Recipients panel and click Add recipient. Enter:

• Name (required)
• Email (required)
• Role label (optional, for your own tracking, e.g. “Brand”, “Influencer”, “Manager”)

Add as many recipients as your plan allows. The free Solopreneur tier allows up to 3 signers per envelope; paid plans allow more.

Reorder recipients by dragging them in the panel. Order matters if you’re using sequential signing (see next entry). For parallel signing, order is informational only.

Each recipient shows up as a color-coded avatar in the field editor. Assign fields to specific recipients by clicking a field and picking the recipient in the right rail.

When you have multiple signers, choose the flow:

• Sequential (signInOrder: true): signers get their links one at a time. Signer B does not receive an email until signer A completes. Useful when the order matters legally or procedurally (e.g. the manager must sign after the employee).
• Parallel (signInOrder: false): everyone gets their link at Send time. Signers can complete in any order. The envelope finalizes when the last signer is done.

Sequential is safer for contracts where subsequent signers need to see previous signatures. Parallel is faster for envelopes where signers act independently (e.g. both parties acknowledging separate NDAs).

Before you send, click Preview at the bottom of the field editor. Preview composites your static sender elements over the PDF and shows signer fields as they’ll appear on the signer’s side.

Preview lets you catch:

• Fields placed off-page or over important content
• Static elements that overlap signer fields
• Text blocks that got clipped at page edges
• Overall visual quality of the final document

Once you’re happy with Preview, close it and click Send. Preview is non-destructive, meaning it doesn’t send the envelope or issue signer links.

Clicking Send triggers a specific sequence on the server:

1. Flatten sender elements into the PDF. Static elements you placed (text, images, QR codes) get baked into the actual PDF pixels. If this step fails, the envelope stays in draft.
2. Generate signer tokens. Each recipient gets a unique, unguessable token that anchors their signing link (/sign/:token).
3. Move envelope to pending status.
4. Send emails. Sequential envelopes send only the first signer’s email; parallel envelopes send everyone’s at once.

What the signer sees is authoritative: the flattened PDF plus your interactive signer fields. There is no way for the sender to change static content after send.

For envelopes with more than roughly 100 pages, Send becomes asynchronous. The API returns 202 Accepted immediately, and a background worker performs the flattening and dispatch.

The UI shows a progress bar via server-sent events (SSE): flattening, hash calculation, dispatch, complete. During this time the envelope is in a transitional “sending” state.

• Sender does not need to keep the browser tab open, they can close it and come back.
• Once complete, the envelope moves to pending and signer emails go out.
• If something fails during the background process, the envelope stays in draft with an error attached and you can retry.

Small envelopes (under ~100 pages) are synchronous, meaning Send finishes in one HTTP call and moves straight to pending.

If you catch a mistake in the source PDF before any signer has signed, you can replace the underlying document without losing your field placements. In the draft editor, click Replace PDF and upload the new version.

Guardrails on this action:

• Only allowed on draft or pending envelopes with zero signatures yet. Once a signer has signed even one field, the PDF is locked.
• Version history is kept. The old PDF, along with which version each event acted on, is retained in the audit trail.
• Fields keep their coordinates. If your new PDF has the same layout, fields land in the right place. If the layout changed, you may need to reposition fields.