Skip to content
Last updated

Integration

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.

Key concepts

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.

Integration approaches

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.

Approach 1: Fully automated (API-only)

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.

Signer (email/SMS)Docue APIIntegrator backendSigner (email/SMS)Docue APIIntegrator backendRepeat for each participantPOST /sign/sessions (files, participants, invitations, webhooks, start: true)Session created & startedInvitations sent automaticallyOpens signing_url → signs in Sign UIWebhook: participant signedWebhook: session completedGET /sign/sessions/{id}/pdfSigned PDF
Signer (email/SMS)Docue APIIntegrator backendSigner (email/SMS)Docue APIIntegrator backendRepeat for each participantPOST /sign/sessions (files, participants, invitations, webhooks, start: true)Session created & startedInvitations sent automaticallyOpens signing_url → signs in Sign UIWebhook: participant signedWebhook: session completedGET /sign/sessions/{id}/pdfSigned PDF

This approach works best when your system already has all the required information (files, participant names, emails, and preferred signing methods).

Approach 2: Prepare and let the end-user finalize (Sender UI)

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.

SignerDocue APIIntegrator backendEnd-user (sender)SignerDocue APIIntegrator backendEnd-user (sender)POST /sign/sessions (files, participants)Session created (pending)POST /sign/sessions/{id}/sender-uisSender UI URLRedirect to Sender UIReviews participants, configures invitations, starts sessionRedirected back via return_handlerInvitations sentSigns in Sign UIWebhooks: status updates
SignerDocue APIIntegrator backendEnd-user (sender)SignerDocue APIIntegrator backendEnd-user (sender)POST /sign/sessions (files, participants)Session created (pending)POST /sign/sessions/{id}/sender-uisSender UI URLRedirect to Sender UIReviews participants, configures invitations, starts sessionRedirected back via return_handlerInvitations sentSigns in Sign UIWebhooks: status updates

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).

Approach 3: End-user drives everything (Sender UI)

You create an empty signing session and let the end-user upload files, add participants, and manage the entire process through the Sender UI.

SignerDocue APIIntegrator backendEnd-user (sender)SignerDocue APIIntegrator backendEnd-user (sender)POST /sign/sessions (empty or minimal)Session created (pending)POST /sign/sessions/{id}/sender-uisSender UI URLRedirect to Sender UIUploads files, adds participants, configures invitations, starts sessionRedirected back via return_handlerInvitations sentSigns in Sign UIWebhooks: status updates
SignerDocue APIIntegrator backendEnd-user (sender)SignerDocue APIIntegrator backendEnd-user (sender)POST /sign/sessions (empty or minimal)Session created (pending)POST /sign/sessions/{id}/sender-uisSender UI URLRedirect to Sender UIUploads files, adds participants, configures invitations, starts sessionRedirected back via return_handlerInvitations sentSigns in Sign UIWebhooks: status updates

Session lifecycle

A signing session moves through the following states:

  1. pending — The session has been created. Files and participants can still be added or removed. Participants cannot access the Sign UI yet.
  2. started — The session is locked. No files or new participants can be added. Participants can now access their signing_url and sign the document. Invitations can be sent.
  3. 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.
  4. cancelled — Signing was cancelled after the session started. Participants still can access the document, but can not add new signatures.
  5. expired — The session expired before it was completed.
  6. 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.