DocuSign Embedded Signing Workflow

Question

Using this python example from github as an example, I wrote an R package for interacting with the DocuSign embedded signing API.

I don't appear to fully understand the workflow for embedded signing, and I am hoping someone can help.

Here is what I would like:

I have an application with a sign up page. When users sign up I would like them to sign a document. So when they submit the sign up form, I generate an envelope using a template, and use their name and email in the templateRole parameter. I get a URL which I send the user to, which allows them to sign the document.

It appears though that the actual workflow involves sending an email to the signer first, and having them sign from a link in the email. This does not seem very "embedded" so I am a bit confused. Is this because I am using the sandbox API?

I see that that there is an authenticationMethod parameter, which takes values of either email, or HTTPBasicAuth or Password or PaperDocuments. Is this the reason it is using email instead of directly sending the user to a page where they can sign because I am chooseing email as the authenticationMethod?

Have I fundamentally misunderstood embedded signing?

Answer 1

The script you are referencing is for Embedded Sending.

The Embedded Sending view of an envelope allows users to edit the tabs, documents, recipients, and other settings of draft envelopes before sending them out for approval

So you are basically giving the Signer access to potentially modify the envelope(Add more signers, remove documents etc). The sender view should never be presented to the Signer.

---

If you are looking for Embedded Signing, then see this code

Embedded Signing - or the Recipient View workflow - allows users to sign directly through your app or website. When you embed your recipients you are telling the DocuSign platform your app will generate signing URLs, authenticate your recipients, present the signing request, and re-direct once the transaction is complete.