The Embedded endpoints are used to generate a sign_url used for embedded signing and edit_url used to edit an existing template.
Context: The embedded workflows powered by Dropbox Sign require a special embedded url to give your users access to the related documents on the front end of your app. This url is used with the hellosign-embedded library to embed the experience for your user to interact with.
The Dropbox Sign API offers three embedded workflows: Embedded Signing, Embedded Templates, and Embedded Requesting. Each approach uses it’s own distinct embedded url:
For terminology details, see the glossary entries for Embedded Signing and Embedded Unclaimed Draft.
Embedded Signing uses a sign_url that must be generated by calling /embedded/sign_url/{signature_id}. For embedded signature requests with multiple signers, a unique sign_url is needed for each signer. Since the sign_url will expire after a period of time, you should wait to generate the url until the user is ready to sign.
Embedded Templates use an edit_url, which is generated during the initial /template/create_embedded_draft call. However, in order to edit that template later, you’ll need to call /embedded/edit_url/{template_id} to generate a new edit_url.
Embedded Requesting uses a claim_url, but has no dependencies on the methods present in the Embedded object.
The Embedded object is returned with an embedded url and time until it expires.