Signing sessions let you collect legally binding digital signatures on PDF documents through the Embed API. The signing flow is built around two hosted UIs and a flexible session model that supports different levels of automation.
Sender UI — A hosted interface for the person who is requesting signatures. In the Sender UI the end-user can manage files, add or edit participants, configure invitations, and start the signing session. You create a Sender UI via POST /sign/sessions/{session_id}/sender-uis and redirect the end-user to the returned one-time URL.
Sign UI — A hosted interface for the person who is signing the document. For manual delivery, each invitation includes a signing_url. Opening this URL takes them directly to the Sign UI where they can review the document and sign using one of the allowed signature methods.
There are three main approaches to integrating the signing flow, depending on how much control you want to give your end-users through the hosted Sender UI.
The most straightforward approach. You prepare everything on your side and create a complete signing session in a single API call. Invitations are sent automatically and you track progress through webhooks.
This approach works best when your system already has all the required information (files, participant names, emails, and preferred signing methods).
You prepare the file and an initial set of participants via the API, then let the end-user review, adjust, and send invitations through the Sender UI.
Use the configuration.editable_parts option when creating the Sender UI to control which parts the end-user can modify (e.g. only participants and invitations, but not files).
You create an empty signing session and let the end-user upload files, add participants, and manage the entire process through the Sender UI.
A signing session moves through the following states:
pending— The session has been created. Files and participants can still be added or removed. Participants cannot access the Sign UI yet.started— The session is locked. No files or new participants can be added. Participants can now access theirsigning_urland sign the document. Invitations can be sent.completed— All participants have signed. The audit log and signing evidence are packaged into the PDF at this point. Download the final document once, after the status changes.cancelled— Signing was cancelled after the session started. Participants still can access the document, but can not add new signatures.expired— The session expired before it was completed.discarded— The session was discarded before it started.
Important: Because the document is digitally signed in sequence, no new participants can be added once the session has been started. The cryptographic signature chain is established when the session starts, so the participant list must be finalized before that point.