August 19, 2026
The short answer: choose embedded sending when the person preparing and sending documents must stay inside your product, and choose remote sending when speed of integration matters more than owning every pixel of the sender experience. Both models use the same e-signature API underneath — the difference is who renders the sender's workflow, your application or the signature provider.
This guide defines both models precisely, compares them on the dimensions that actually decide projects, and gives you a decision checklist you can apply to your own roadmap.
What embedded sending means
With embedded sending, the entire prepare-and-send flow runs inside your application. Your user uploads or generates a document, places signature and form fields, adds recipients, and clicks send — all in a UI you host, usually delivered by the provider as an embeddable component or an authenticated, tokenized view.
From the sender's perspective, your product is the signature tool. Your brand, your navigation, your session. The provider's API does the heavy lifting in the background: envelope creation, field validation, notifications, signing ceremony, and final document storage.
Embedded sending demands more engineering. You must manage sender authentication, request the embedded view with short-lived tokens, handle session expiry mid-flow, and build fallback states when the embedded session breaks. In return, you get a seamless experience and full control over who touches the sending flow — which is exactly why SaaS products that resell signing as a feature choose it.
What remote sending means
Remote sending is the default API model. Your backend creates the envelope through a REST call — documents, recipients, fields, message — and the provider takes it from there. Recipients get an email, click through to the provider's hosted signing page, and sign. Senders track status in your app via webhooks or polling, but any hands-on preparation happens in the provider's own UI.
The sender experience is a hand-off: your app initiates, the provider's interface executes. That hand-off is also the model's strength. Integration can be live in days, the provider maintains the sending UI, its mobile compatibility, and its accessibility, and your team never has to build field placement or recipient management screens.
Most API e-signature products document remote sending first because it is the lowest-friction path. Our walkthrough of getting started with Nota Sign e-signature shows what that pattern looks like end to end.
Embedded vs. remote sending: side-by-side comparison
Neither model changes the legal validity of the resulting signature; they change who builds and maintains the sender's experience.
How to choose: a decision checklist
Work through these questions in order — the first decisive answer usually settles it.
Does the sender need to stay in your product? If your customers prepare contracts inside your SaaS and would see a third-party page as a jarring hand-off, embedded sending is the only acceptable answer. If senders are your own employees, remote sending is almost always enough.
How much engineering capacity can you commit? Embedded sending is an ongoing product surface, not a one-time integration. If you cannot staff session handling, error states, and UX regression testing, remote sending's provider-hosted UI is the pragmatic choice.
What does the pricing model reward? API plans are commonly metered per envelope, and the two models can sit in different tiers. Review the HelloSign vs DocuSign pricing comparison and this Acrobat Sign vs Dropbox Sign review before committing — the wrong tier can erase embedded sending's UX gains.
Do you need a hybrid? Many teams ship remote sending first for speed, then add embedded sending for their highest-volume sender segment once the envelope API is stable. Because both models share the same envelope lifecycle, the migration path is additive, not a rewrite.
If you are still surveying platforms, our provider evaluation guidance compares vendors on exactly these integration dimensions.
Implementation details that decide success
Whichever model you choose, four technical decisions determine whether the integration holds up in production.
Status synchronization. Never treat a redirect or a button click as completion. Subscribe to webhook events and reconcile them against envelope status polling, so a dropped notification never leaves a signed document invisible to your system.
Idempotent envelope creation. Retries after a timeout must not create duplicate envelopes. Send an idempotency key or a client-side envelope reference and make your retry logic safe by design.
Mobile and iframe constraints. Signing and preparation flows on mobile devices often require the system browser rather than an embedded webview, and some provider components restrict iframe embedding for security. Test your embedded views on real devices early — this is the most common late-stage surprise.
Template strategy. If senders repeatedly prepare similar documents, pre-built signature templates shrink the sender's job to filling variables — valuable in both models, but especially powerful when combined with embedded sending's controlled UX.
Finally, model the total cost before you commit: envelope volume, API tier, and any per-seat fees all interact. The multi-user DocuSign cost analysis breaks down how these cost drivers differ across vendors.
Build your signing integration: Nota Sign
Nota Sign is FaDaDa's global e-signature platform, built on infrastructure that IDC has ranked #1 in China's e-signature software market for consecutive years. Its open API supports both integration models described here — remote sending for fast launches and embedded flows for products that resell signing — with the full reference available in the Nota Sign API documentation.
What development teams get from the Nota Sign API:
- Developer-friendly RESTful API. Predictable resources, clear authentication, and sandbox access, so your team can integrate quickly.
- Secure signing flows and document management. Certificate-based tamper-evident sealing, complete audit trails, and full envelope lifecycle control over the API.
- Flexible interfaces that fit existing systems. Webhooks, idempotent envelope creation, and embeddable components adapt to your current stack instead of forcing a rebuild.
- Streamlined signing, automated business. Templates, bulk sending, and event-driven status sync remove manual steps from your document workflows.
- Fast to test, deploy, and scale. Sandbox-first onboarding, then production rollout backed by legal coverage across 100+ countries and regions, APAC compliance depth including iAM Smart, Singpass, and SES/AES/QES signature levels, and regional data centers.
Nota Sign charges no per-seat fees, which keeps it friendly for small teams embedding signing for the first time, and offers tailored plans for mid-market and enterprise integrations. To scope your embedded or remote sending architecture with our team, get in touch.
