Skip to main content

Embedded signing

Embedded signing integrates the document signing experience directly into your application. Instead of recipients receiving an email and navigating to a separate page, signing happens within your own product — in an iframe or as a redirect within your application's flow.

When to use embedded signing​

Embedded signing is well-suited for:

  • Keeping users within your application during onboarding, checkout, or approval workflows
  • Collecting signatures immediately as part of a defined product flow
  • Maintaining brand consistency throughout the signing experience
  • Applications where email-based signing would interrupt the user journey
Coming Soon

Screenshot: embedded-vs-email-comparison — side-by-side comparison of email and embedded signing flows

How it works​

Embedded signing follows a server-driven flow. Your backend is responsible for creating the agreement and generating a signing session URL. Your frontend then presents that URL to the user.

Step 1: Create the agreement​

Your backend creates an agreement using the Sign API, designating the recipient as an embedded signer by including a clientUserId that corresponds to the user in your system.

Step 2: Generate a signing session​

Your backend requests a signing session URL for the recipient from the Sign API. This URL is scoped to that recipient and agreement. Pass a returnUrl so the user is redirected back to your application after signing completes.

Step 3: Present the signing URL​

Your frontend receives the signing URL from your backend and presents it to the user — either embedded in an iframe or as a redirect to the signing page.

Never expose API credentials to the frontend

Signing session URLs must be generated server-side. Your API credentials should never be sent to or used from the browser. Fetch the signing URL from your own backend endpoint, then pass only the URL to your frontend.

Display options​

Iframe embed

Render the signing URL in an <iframe> element within your page. This keeps the user on your page while they sign.

Redirect

Navigate the user directly to the signing URL. After signing, the returnUrl you specified brings them back to your application.

New window

Open the signing URL in a new browser tab using window.open(). This is the least integrated option but requires no special embedding.

Authentication​

Because your application authenticates users before generating signing URLs, the signing session relies on your authentication as the primary trust signal. You can optionally layer additional verification on top — such as an access code or SMS code — using the agreement's authentication settings.

Only generate and deliver signing URLs to users you have already authenticated in your application.

After signing​

When the recipient completes signing, they are redirected to the returnUrl you specified when generating the signing session. Use this URL to return them to the appropriate step in your application flow (for example, a success screen or next onboarding step).

You can also configure webhooks to receive server-side notifications when signing events occur, such as a recipient completing or declining.

Implementation reference​

Full API documentation for creating agreements and generating embedded signing sessions is available in the Sign API reference. The API follows DocuSign-compatible envelope and recipient patterns.

Security best practices​

  • Always generate signing URLs server-side — never expose API credentials to the browser
  • Authenticate the user in your application before generating a signing URL
  • Do not cache or store signing URLs — generate a fresh URL when the user reaches the signing step
  • Use a specific returnUrl so users return to the correct place in your flow after signing
  • Email signing — Alternative signing method that does not require backend integration
  • Authentication — Configure additional identity verification for embedded signers
  • Sign API reference — Complete API documentation for programmatic agreement creation