Embedded signing vs email signing: when to use each
"Embedded" means different things depending on which side of a signature request you're talking about: embedding the sender's experience of creating and managing signature requests inside your own application, versus embedding the signer's experience of actually completing a document. The two aren't always the same feature, and it's worth being precise about which one a given platform actually offers before assuming it covers your use case.
Email-based signing, the default path
By default, when you create a signature request — through a dashboard or through an API — each signer receives an email with a unique, individually addressed link. Opening it takes them straight to the document, where they review and complete their assigned fields. No account or login is required on the signer's side. This is the standard path, and it's what actually delivers the document to a signer regardless of how the request was created.
What Esignapi's embed capability actually covers
Esignapi's embed API lets you render a document and signature request management panel inside your own application, authenticated with a dedicated embed token rather than your main API key. Through that embedded panel, a user of your application can list and view documents, create and cancel signature requests, and download completed documents and certificates — all without leaving your product or being redirected to Esignapi's own dashboard. The signers on a request created this way still receive their documents through the standard secure email link; the embedding here is on the sender/management side, not a separate signer-facing signing widget.
Why that distinction matters before you build around it
If your goal is to let signers complete a document without ever leaving your application's interface, it's worth confirming directly, for whatever platform you're evaluating, whether that specific capability exists — some platforms embed only the sender's management experience, as described above, while others build a dedicated in-app component for the signer's own completion flow. Assuming the word "embedded" automatically means "the signer never leaves my app" can lead to a mismatch between what you expected and what you actually integrate.
When embedding the management panel is the better fit
- You're building a product where your own users (not their external counterparties) need to send and track signature requests without ever opening a separate Esignapi dashboard tab.
- You want document and request management to feel like a native part of your product, with your own navigation and branding around it, even though the signing itself still happens through the standard emailed link.
- You're building a platform on top of Esignapi for your own customers, and want them to manage their own signature requests inside your interface rather than needing their own separate Esignapi login.
When the standard dashboard is simpler
If the people sending documents are your own internal team, and they're comfortable using Esignapi's own dashboard directly, there's no integration overhead to embedding anything — the dashboard already provides the full sending and tracking experience without any development work on your side.
What stays the same either way
Regardless of whether requests are created through the embedded panel, the API directly, or the standard dashboard, signers always go through the same underlying signing process: a secure, individually addressed link, the same field types and positioning, the same completion certificate and audit trail once they're done. Embedding changes where the sender manages requests — it doesn't change how a signer experiences signing.
Authorizing the embed panel securely
The embed panel is authorized with its own dedicated token rather than your main API key, which limits what it can do compared to full API access and avoids exposing your primary credential to the browser context the panel runs in. Requesting and issuing that token should still happen from your own backend, not directly from client-side code your end users can inspect.
What it costs to integrate each approach
Using the standard email-based flow through the API requires no additional integration beyond calling the endpoints that create and track requests — there's no separate embed-specific setup. Embedding the management panel adds a layer: requesting and securing an embed token server-side, rendering the panel inside your own layout (typically in an iframe), and handling the postMessage events it emits so your own application can react to what the user does inside the embedded panel, such as a new request being created. That extra integration work is the tradeoff for a more seamless, native-feeling experience for the people using your product.
A concrete example of where this distinction matters
Imagine you're building a property management platform where landlords (your own users) send leases to tenants (external parties who've never heard of Esignapi). The landlord's side of this — uploading the lease, adding the tenant's email, tracking whether it's been signed — is exactly the use case for embedding the management panel inside your landlord-facing dashboard, so landlords never need a separate login. The tenant's side — receiving and completing the lease — happens through the standard emailed signing link regardless of how the landlord created the request, since tenants are external parties who aren't using your product directly in the first place.
Build your product's management experience around it
Esignapi's embed API lets you surface document and signature request management inside your own application, while the REST API remains available for building your own fully custom signer-facing flow on top of the same signature request data.
Thinking about this as two independent decisions
It helps to treat "how do my own users manage requests" and "how do signers complete documents" as two separate decisions rather than one combined choice. The first is genuinely yours to make, with the embed panel as one option alongside the standard dashboard. The second — how signers actually complete a document — isn't really a decision you need to make at all for a straightforward integration, since it happens the same way (a secure emailed link) regardless of which management approach you picked. Keeping these separate in your own planning avoids assuming that choosing to embed the management side also changes something about the signer's experience, which it doesn't.
Frequently asked questions
Does Esignapi let signers complete a document without leaving my app?
Signers complete documents through the standard secure link delivered by email; Esignapi's embed capability specifically covers embedding the sender-side document and request management experience, not a separate signer-facing signing widget.
Is the embedded panel authenticated the same way as the main API?
No — it uses its own dedicated embed token rather than your main x-api-key, which keeps the credential used in a browser-embedded context separate from your primary API key.
Can I use the embed panel and the direct API together?
Yes, nothing about using the embed panel for management prevents you from also calling the REST API directly for other parts of your integration, such as creating requests programmatically from a backend process.
Do signers need an Esignapi account to complete a document, embedded panel or not?
No, in either case signers access and complete documents through their unique link without needing to create an account or log in.
Confirm directly, in that platform's own current documentation, whether "embedded" refers to the signer's completion experience specifically, or to embedding sender-side management — the terminology is used inconsistently enough across the industry that it's worth verifying rather than assuming.