Skip to main content

Embedded Signing

Embedded signing lets you bring document signing inside your own application. Instead of recipients receiving an email and going to a separate page, signing happens within your product, as part of your onboarding, checkout, or approval flow.

This is a developer integration. Your engineering team implements the flow using the Propper Sign API.

When to Use It​

  • You want users to stay inside your application while they sign
  • Signing is a step in a defined product flow (e.g., account activation, contract approval)
  • You need to maintain brand consistency throughout the experience
  • Email-based signing would interrupt or break the user journey

How It Works​

Your backend creates the agreement and generates a signing URL. Your frontend presents that URL to the user, either embedded in an iframe or as a redirect.

Step 1, Create the agreement Your backend calls the Sign API to create an agreement, designating the recipient as an embedded signer using a clientUserId that maps to the user in your system.

Step 2, Generate a signing URL Your backend requests a signing session URL for that recipient. Pass a returnUrl so the user is redirected back to the right place in your app after signing.

Step 3, Present the signing URL Your frontend receives the URL from your backend and displays it, either in an <iframe> on the page, or as a full redirect.

caution

Signing session URLs must be generated server-side. Never expose API credentials to the browser. Your frontend should only ever receive the URL, not the credentials used to generate it.

Display Options​

OptionHow it works
iframeEmbed the signing URL in an <iframe>, the user stays on your page while signing
RedirectNavigate the user directly to the signing URL; the returnUrl brings them back after
New windowOpen the signing URL in a new tab, least integrated, but simplest to implement

After Signing​

When the recipient finishes, they're redirected to the returnUrl you specified. Use this to send them to a confirmation screen or the next step in your flow.

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

Identity Verification​

Because your application handles authentication before generating signing URLs, the signing session relies on your authentication as the primary trust signal. If you need an additional layer, you can configure identity verification on the recipient, such as an access code or SMS code, on top of your app's authentication.

Implementation Reference​

Full API documentation is in the Sign API reference, including how to create agreements, add embedded recipients, and generate signing session URLs.