
A signing experience presented within an application or website, distinct from a hosted signing link, embedded preparation or complete white-label branding.
Embedded signing presents a recipient’s signing experience inside another application or website, rather than simply sending them to a separately hosted signing page. The host application integrates a signing component or supported session, while the signing service provides the underlying signing workflow.
Embedded recipient signing, embedded request preparation and embedded template editing are distinct interfaces. An integration can provide one without providing all three.
API operations typically prepare or identify the request and obtain whatever signing access the provider supports. The application must present the intended recipient’s session and protect signing links or tokens according to the provider’s requirements. Private API credentials do not belong in a public browser merely because the signing interface is displayed there.
The signer still needs access to the relevant document and an opportunity to complete the required actions. A host application’s “finished” screen or redirect is not, by itself, authoritative confirmation that the whole request is complete. Use supported signing-event notifications or status queries to confirm the actual result.
Check supported embedding methods, recipient access, session lifetime, branding, authentication and any permitted redirect or framing domains.
For programmatic request creation, routing and retrieval, explore the Sign.Plus API offering and developer documentation. Plan the recipient interface separately using the embedding and access methods documented for your integration.
A Common Case: Evaluating signing within a client portal
A Washington financial-services firm planning client onboarding can ask whether its selected provider supports recipient signing within the portal or redirects to a hosted page. Its design then separates the interface from status confirmation, recipient checks and the specific branding options actually available.
No. Embedded signing concerns where the interface appears; white-labeling concerns branding and attribution, with customization limits set by the provider.
No. Programmatic request management and a supported embedded recipient interface are separate capabilities to verify.
No. Confirm the request’s actual status through the provider’s supported event or status mechanism; one browser session does not establish completion by every recipient.