\n
\n
![\"Embedded\"](\"/img/soap_ref/RequestRecipientToken%28Embedded%29.png\")
\nCreating envelops for Embedded Recipients parallels the Remote Recipient model. But sender needs to specify if the recipient is Remote or Embedded. Sender can do this by using ClientUserId. A non-null ClientUserId implies that user is Embedded. A single envelope can contain both Embedded and Remote Recipients.
"},"sys":{"type":"Entry"},"internal":{"type":"ContentfulAssemblyHtmlSection"}},{"id":"1c1c5a8f-6ba1-562b-9028-54c4e4918ad2","contentful_id":"2qPaWbAqwlItYGTjkdxUbP","node_locale":"en-US","heading":"Requesting Recipient Tokens (RequestRecipientToken and RequestRecipientFaxToken)","headingLevel":2,"sectionId":null,"multicolumn":true,"noBorder":false,"backgroundKind":null,"paddingTop":null,"paddingBottom":null,"html":{"html":"Docusign constrains access to the Embedded signature process via short-lived Recipient Tokens. Successful token requests return an URL that will invoke the Docusign signing wizard for a particular envelope and Embedded Recipient. Envelopes must be sent before a recipient token can be requested (recipient tokens will not work with draft envelopes).
Important: iFrames should not be used for embedded operations on mobile devices due to screen space issues. For iOS devices Docusign recommends using a WebView.
There are two types of recipient tokens available:
This section describes the token methods and the behaviors.
The RequestRecipientToken and RequestRecipientFaxToken methods use the format and rules, and are divided into three sections: Entity Identification, Authentication Assertions and InSessionCallBackURL.
\nThe following parameters identify the Envelope and Captive Recipient for which the Recipient Token is requested:
Note: When requesting a Recipient Token, the ID in ClientUserID must use upper-case letters. If lower-case letters are used (ClientUserId) an error will occur.
The Username and Email identifies a unique recipient and ClientUserID specifies if the recipient is Embedded or Remote. All the three parameter together identifies a Captive Recipient. All values must exist and correlate to a valid Envelope/Embedded Recipient entity relationship in order for the RequestRecipientToken request to succeed.
"},"sys":{"type":"Entry"},"internal":{"type":"ContentfulAssemblyHtmlSection"}},{"id":"7e89d74c-8861-59ca-b27e-7b379a763f96","contentful_id":"5S43qJx3Mq1AmyMASgdr4z","node_locale":"en-US","heading":"Authentication Assertions","headingLevel":2,"sectionId":null,"multicolumn":false,"noBorder":false,"backgroundKind":null,"paddingTop":null,"paddingBottom":null,"html":{"html":"Docusign acts as a Single Sign-On consumer to the API client application in the Embedded Signing model. That is, Docusign trusts that the client application authenticated the end-user sufficiently to establish their identity and offer documents to sign or view. This is critical to the seamless integration between the two applications, and it is necessary since Docusign has no interaction with the end-user prior to displaying the documents. However, even though the trust relationship does not include a Docusign-verification of the user identity, Docusign requires the client application to assert that it has authenticated the end-user through some means. This assertion is communicated through the following parameters:
An entry is added into the Security Level section of the Docusign Signing Certificate that reflects the “SecurityDomain – AuthenticationMethod” used to verify the user identity. Additional identity verification within Docusign is optionally available through the ID Check and Access Code features.
"},"sys":{"type":"Entry"},"internal":{"type":"ContentfulAssemblyHtmlSection"}},{"id":"8c07258a-be31-5fec-9aeb-c3ad8189f65f","contentful_id":"7zt7mLXzAx0NnEoSwM5J7R","node_locale":"en-US","heading":"ClientURLs","headingLevel":2,"sectionId":null,"multicolumn":false,"noBorder":false,"backgroundKind":null,"paddingTop":null,"paddingBottom":null,"html":{"html":"Client application will have the option of setting Client URLs to be called on specific Docusign events. Docusign redirects the Recipient to the URL.
If you want an “event” parameter or any other parameters, you MUST provide them in the callback URL. The valid values are listed in Embedded Callback Event Codes.
"},"sys":{"type":"Entry"},"internal":{"type":"ContentfulAssemblyHtmlSection"}},{"id":"f577cea9-c493-541a-b7d7-fa1dac5a5662","contentful_id":"22vZv1RCbZ1NcJ5Fsfjg1i","node_locale":"en-US","heading":"XML Signing","headingLevel":2,"sectionId":null,"multicolumn":false,"noBorder":false,"backgroundKind":null,"paddingTop":null,"paddingBottom":null,"html":{"html":"It is recommended that embedded clients sign the body of the RequestRecipientToken message with a valid X.509 certificate. This process supports the Single Sign-On trust relationship between Docusign and the client application. Client organizations must provide Docusign with the certificate’s Common Name (CN) during the implementation phase so that Docusign can validate the XML signature. Supported certificate authorities are VeriSign and Thawte.
"},"sys":{"type":"Entry"},"internal":{"type":"ContentfulAssemblyHtmlSection"}},{"id":"6d28c7ae-8448-5d85-935a-6496b7802927","contentful_id":"5rVBS7ctAvd0T0DqgJXpkQ","node_locale":"en-US","heading":"Expiration","headingLevel":2,"sectionId":null,"multicolumn":false,"noBorder":false,"backgroundKind":null,"paddingTop":null,"paddingBottom":null,"html":{"html":"Recipient Tokens must be requested (and returned) in order to sign or to view envelope documents. The Docusign web application renders the view that is appropriate to the state of the envelope for the Recipient. The logic is as follows: