If your SaaS product asks customers to sign an agreement during onboarding, checkout, account activation, or an approval workflow, the signing experience becomes part of your product experience.
Sending a user to a separate signing page can be simple to implement, but it may interrupt the task they were trying to complete. Embedding a signing experience can make the workflow feel more integrated, but it may require more engineering, session management, testing, and ongoing maintenance.
The right choice depends on who signs, where the signing request begins, how much control your product needs, and what your e-signature provider supports.
The three common signing approaches
Embedded signing
The signing interface is presented within your application or an integrated view, subject to the provider's supported implementation. The user can remain close to the product workflow that initiated the request.
This approach may suit onboarding, customer portals, loan or service applications, and internal approval flows where the signer is already using the SaaS product.
Redirect-based signing
Your application sends the user to a separate signing page or signing session. After the signing process, the user may be returned to your application.
Redirects can be simpler to implement and can provide a clear boundary between your application and the signing interface. They are often suitable when a fully embedded experience is not necessary or is not supported by the provider.
Email signing links
Your application or backend initiates a signature request, and the signer receives a link by email. This is especially useful when the signer is an external customer, supplier, contractor, or other person who may not be logged in to your SaaS product.
Email signing is not necessarily a competing architecture. A product may use embedded signing for logged-in users and email links for external participants.
Compare the options before choosing
| Consideration | Embedded signing | Redirect signing | Email signing link |
|---|---|---|---|
| User experience | Can keep signing close to the product workflow | Takes the user to a separate signing page | Lets the signer open the request from their inbox |
| Implementation | May require more integration and session handling | Often simpler to connect to an external signing flow | Requires reliable request creation and delivery |
| External signers | Depends on how access is designed | Can work well for users outside the application | Often suitable for signers who do not have a product account |
| Branding | Depends on provider and embedding capabilities | Depends on the provider's signing page and configuration | Email and signing-page branding depend on available controls |
| Failure handling | Requires handling embedded-session and application states | Requires handling redirects, return paths, and expired sessions | Requires handling delivery failures, expiration, reminders, and incomplete requests |
| Best fit | Signing is a natural step inside the product | A separate signing step is acceptable | Signing can happen independently of the user's current session |
No option is universally better. Test the complete flow, including failure cases, rather than choosing based on the interface alone.
Choose the flow based on the user journey
Scenario 1: A SaaS product collects customer agreements during onboarding
If a new customer must sign before completing setup, embedded signing may reduce the sense of leaving the product. A redirect can also work if the return path is clear and the user can resume onboarding without losing progress.
Check what happens if the signer closes the tab, the signing session expires, or the document is not completed. The application should show a clear status and provide a safe way to resume.
Scenario 2: A CRM sends a contract to a customer
The employee using the CRM may initiate the request, but the customer is not necessarily logged in to the CRM. An email signing link may be the most natural approach. The CRM can then reflect the signature status when it receives a verified event or checks the request status through the supported integration.
Scenario 3: A vendor portal needs supplier approval
If suppliers already use a portal, embedded or redirect signing may be suitable for logged-in users. If the supplier's representative should not need a portal account, an external signing link may be simpler. The access model should match the sensitivity of the document and the identity assurance required.
Scenario 4: A high-volume workflow sends similar documents to many recipients
The central challenge may be request creation, status tracking, and exception handling rather than whether the signing page is embedded. Consider whether bulk signing or an API-driven workflow can reduce repetitive work, while ensuring each recipient receives the correct document.
Technical details that matter more than the visual presentation
A reliable e-signature API integration needs more than a button that opens a signing page.
Protect credentials. Keep API secrets on the server rather than exposing them in browser code or mobile applications.
Validate access. Check that the requesting user is authorized to create or view the relevant signature request. Do not rely only on a document ID supplied by the browser.
Handle signing sessions safely. Use the provider's supported method for creating and expiring signing sessions. Avoid treating a long-lived public URL as proof of identity or authorization.
Verify webhooks. Validate event signatures or other supported verification mechanisms before trusting webhook payloads. Where supported, make event processing idempotent so duplicate notifications do not create duplicate business actions.
Handle asynchronous states. A request may be created, sent, viewed, declined, expired, or completed. Map the provider's actual statuses to your product's workflow and define what happens at each stage.
Design for failures. Consider email delivery failures, interrupted sessions, user retries, network errors, and users opening old links. Provide a clear status and recovery path.
Retain evidence. Determine how completed documents and available audit records are retrieved, linked to your internal record, and retained.
The precise implementation depends on the provider's API and security model. Follow the current integration documentation instead of assuming that every provider supports the same embedding method, event type, or branding control.
How to evaluate an e-signature API for your SaaS
Before selecting a provider, test the workflow from the perspective of both the person sending the document and the person signing it.
- Can the application create a request using the required document and signer information?
- Can internal users and external signers use the appropriate signing method?
- Can the application retrieve completion status reliably?
- Are webhook events authenticated and safe to process more than once?
- Can completed documents and audit evidence be retrieved?
- Does the provider support the required branding and embedding model?
- What happens when a signer declines, the request expires, or delivery fails?
- Are the API limits, pricing, support model, and deployment options appropriate for expected usage?
Undersign can be evaluated as an e-signature workflow option for products that need individual requests, bulk signing, public signing links, or API-based integration. Confirm the exact API endpoints, authentication methods, supported embedding behavior, webhook events, and deployment options against the current product documentation and your requirements before committing to an architecture.
Frequently asked questions
What is the difference between embedded and redirect signing?
Embedded signing presents the signing interface within or closely integrated with an application. Redirect signing sends the user to a separate signing page or session. The practical differences depend on the provider's implementation and the surrounding user journey.
Is embedded signing always better for SaaS?
No. It may provide a more integrated experience, but can require more development and testing. Redirect signing or email links may be better for external signers, simpler workflows, or applications that do not need an embedded interface.
Should a SaaS product use an e-signature API or email signing links?
These are not mutually exclusive. An API can create and manage signature requests, while email links provide one way for recipients to access them. Choose the delivery method based on who signs and how they interact with your product.
What should developers check before integrating an e-signature API?
Review authentication, authorization, request creation, signer access, session expiration, webhook verification, duplicate-event handling, error recovery, document retrieval, audit records, API limits, and pricing.
Can embedded signing improve conversion rates?
It may remove some friction in certain workflows, but results depend on the audience, product, device, document, and implementation. Do not assume a particular improvement without measuring it in your own product.
Can an e-signature integration support both logged-in and external users?
Depending on the provider and implementation, a product may use an embedded or redirected flow for logged-in users and email or public signing links for external users. Confirm the provider's supported access and identity controls.