My sandbox is not redirecting to the landing pages I specify, but rather keep redirecting to the default DocuSign landing pages.
I am attempting to redirect to a site that is not on a www server, so it is just http://foo.com.
Can you please advise as to why I might be getting the failure and if it is indeed required that the hostname for the redirect be www?
I'm able to re-direct without any issues using the http://foo.com URL you have specified, so there must be something else going on with your code. Have you seen the DocuSign API Walkthroughs located here?
http://iodocs.docusign.com/APIWalkthroughs
They demonstrate 9 common use-cases of the DocuSign API and if you look at the bottom 3 you'll see that they are all focused on Embedding functionality. Using the 8th walkthrough, titled Embedded Signing I was able to get this working with the following requests:
1) Create an Envelope from a Template with one embedded recipient
{
"accountId": "221765",
"emailSubject": "DocuSign API Call - Embedded Signing",
"emailBlurb": "This comes from PHP",
"templateId": "9347C7AF-7EEE................",
"templateRoles": [
{
"requireIdLookup": "false",
"email": "fakeemail#gmail.com",
"name": "John Doe",
"roleName": "Signer1",
"clientUserId": "1001"
}
],
"status": "sent"
}
2) Get The Embedded Signing View
{
"returnUrl": "http://foo.com",
"authenticationMethod": "email",
"email": "fakeemail#gmail.com",
"userName": "John Doe",
"clientUserId": "1001"
}
If I sign the envelope or decline, cancel, etc. it sure enough re-directs me to http://foo.com. You can set the clientUserId to whatever value you'd like but just remember to use the same value for that recipient when requesting the embedded signing (recipient) view in the second part.
Related
I'm a SQL dev and somhow I have to solve this problem,
Is there any way to set and order of the sign order on the API?
In my company it's set for 3 people to sign, two 'static'(our directors) and one variable (the new business partner getting registred on our eletronic form)
I know that when doing it manualy we can set an order for the docments to be sent.
Like send the document for the new partner and only after he finishes signing the document is sent to our director already signed.
But is it possible to do via API? If so, how?
I could find anything about it
It is call "routing order" in DocuSign and you can specify it at the API when you add recipients like this:
"recipients": {
"carbonCopies": [
{
"email": "cc#something.com",
"name": "CC Name",
"recipientId": "2",
"routingOrder": "2"
}
],
"signers": [
{
"email": "signer#something.com",
"name": "Signer Name",
"recipientId": "1",
"routingOrder": "1",
Routing order is to tell DocuSign to ask recipients to sign in this order (ascending) from lower to higher. If there are two recipients with the same routing order - they both get it at the same time. If you don't specify routing order - again, they both get it in the same time.
I am developing an automated document preparation process within our Office365 environment (Word Template, SharePoint etc.) and are using Power Apps and Power Automate to prepare and send the document for authenticated signatures via Docusign. I do not want to use the 'out of the box' Docusign Power Automate connectors as I am need to invoke some of the more advanced Docusign capabilities within my Power Apps solution.
I have successfully developed my own Custom Connectors in Power Apps and Power Automate using the REST API capabilities with Docusign and successfully accomplished Oauth2 user authentication and been able to create envelopes and send documents for signature to a single recipient.
My problem is that I am wanting to send a document to multiple recipients using the V2.1 document REST API standards however, it seems I am bumping into an issue with the custom connector in Power Apps/Power Automate.
To ensure I had a correctly constructed JSON list, I used the built in Docusign API development environment sending the document to multiple recipients along with a document anchortag. It functioned correctly and resulted in the following JSON code:
{
"documents": [
{
"applyAnchorTabs": "True",
"documentBase64": "<Base64BytesHere>",
"documentId": "1",
"fileExtension": "txt",
"name": "NDA Agreement",
"pages": "3"
}
],
"emailSubject": "Testing Docusign",
"recipients": {
"signers": [
{
"email": "wilson.smith#email.com",
"name": "Wilson Smith",
"recipientId": "1",
"roleName": "Vice President",
"routingOrder": "1",
"tabs": {
"signHereTabs": [
{
"documentId": "1",
"pageNumber": "3",
"tabLabel": "CompanySigner"
}
]
}
},
{
"email": "john.doe#gemail.com",
"name": "John Doe",
"recipientId": "2",
"roleName": "President",
"routingOrder": "2",
"tabs": {
"signHereTabs": [
{
"documentId": "1",
"pageNumber": "3",
"tabLabel": "RecipientSignature"
}
]
}
}
]
},
"status": "Sent"
}
I used this as the sample payload to import into the Request section of the DEFINITION page of the Custom Connector:
Request section of Definition Page in Power Automate Custom Connector
This results in a 'body' being developed in the REQUEST section. Opening up the BODY section of the REQUEST reveals the following elements:
Body of Request after importing JSON payload
It can be seen that there are only elements for a single recipient listed in the JSON payload.
It is further confirmed when you go to test the Custom Connector, the test page appears as follows:
Custom Connector Test Page
The test page successfully executes however, it is only sending to a single recipient. It is not identifying the need to send to multiple recipients.
I speculate that Microsoft Custom Connectors are not supporting REST V2.1 and is a limitation. I would appreciate some input on this and, if there is a workaround for this.
Thank you.
Ok, so after crafting the question and issue above, it got me thinking about maybe importing JSON payload directly into the test page (using RAW Body display) and then tested the connector. I was surprised that the JSON code ran with MULTIPLE recipients yet, when I selected back from RAW Body mode), the test page only showed one recipient. This is very misleading.
I then thought that perhaps the connector was configured correctly and it was just a limitation in the connector test process.
I went back to Power Automate and used the multi recipient connector in my flow and was surprised to see that I now had the ability to add multiple recipients and each recipient could be set up with multiple anchor tags.
In summary, the custom connector test is a basic test environment. Going forward, I would use my full JSON payload in the RAW Body view and test it that way. Also, you need to configure the JSON payload to show multiple components to enable Power Automate to configure the use of the connector with these multiple elements.
I think this issue is worth doing a video tutorial on as I am sure many other people will bump into the same issue.
Full transparency, I'm not a web or C# Dev but I inherited a project that is about 90% complete and I'm stuck.
We have a web app that successfully API's the correct data to fields mapped in a DocuSign template but I can't seem to figure out how...or where...to send the person who is filling out data on our web app an email with the DocuSign document.
When the user is finished entering data on our site we redirect to DocuSign successfully, the data is populated as expected and the Sign process completes as expected but the email only comes to the address specified in the DocuSign template under "Add Recipients To Envelope".
Ive looked through some of the DocuSign How To's and any changes I make to the .CS for the DocusignWrapper or RecipientDetails doesnt seem to make any difference.
Hardcoding the email wont work for us since multiple people will be entering data and sending it to the template - so this snip doesnt work for our solution:
"recipients": {
"signers": [
{
"name": "John Doe",
"email": "johnsemail#outlook.com",
"recipientId": "1",
"routingOrder": "1",
},
{
"name": "Jane Smith",
"email": "janesemail#outlook.com",
"recipientId": "2",
"routingOrder": "2",
}
]
}
There are 2 type of recipients for templates:
The "hardcoded" ones that have specified name/email.
Placeholders which only have a role name and email/name would be filled in real-time when envelope is created.
You need to modify your original template to use the latter type. This would allow your API to create the envelope from the template and change the recipients only at that point.
Hope this help.
I ran a quick test using a certified delivery recipient, one document, one signing point. Here is part of that request:
"compositeTemplates": [
{
"serverTemplates": [
{
"sequence": "1",
"templateId": "15a22617-4525-438c-aaf1-45f8632ba2d1"
}
],
"inlineTemplates": [
{
"sequence": "1",
"recipients": {
"signers": [],
"certifiedDeliveries": [
{
"name": "Kathy xxx",
"email": "kathyxxx#gmail.com",
"recipientId": "1",
"accessCode": "12345",
"customFields": [],
"routingOrder": "1",
"note": "",
"roleName": "##Buyer1"
}
]
I noticed if I used a document and template where the roleName matched and there were signing tabs, that the receiver would still be prompted for a signature, even though I put them as a certified delivery. I thought that certified delivery would mean just viewing the document, not ever having to sign it. I guess that's not the case. Is there any way to make sure that the certified delivery person only ever has to view?
Changing a RecipientType on a Server Template just does not feel like a good use of Server Templates. It means you have not defined your server template correctly. You should create another ServerTemplate with the appropriate recipient types and use that instead.
CompositeTemplates allows you to extend your serverTemplates and enables you to overlay document, recipient, and tab definitions from multiple sources.
Sometimes it is better to create your own server template for your specific need rather than extending them using CompositeTemplates.
If you do not want to Create a new server template, you can use the updateEnvelopeRecipients API to update the recipient type.
Here are the steps
Create the envelope as a Draft (Status = 'Created')
Use the updateEnvelopeRecipients API to update the recipient type to CertifiedDelivery. Any tabs that are associated with the recipient will be removed.
Send the Envelope using the updateEnvelope Api.
Another Hack that seems to work. ( I do not recommend this)
You can change the routingOrder of the recipient. The recipient will then be considered as the certified Delivery Recipient as it will no longer match the recipient in the server template.
From Documentation (Expand the compositeTemplates section)
Recipient matching is based on Recipient Role and Routing Order. If there are matches, the recipient information is merged together. A final pass is done on all Composite Templates, after all template overlays have been applied, to collapse recipients with the same email, username and routing order. This prevents having the same recipients at the same routing order.
I have a question on the embedded signing process. As per the API we have to pass the templateId and templateRole which already created earlier.
Can we create the template programmatically using Docusign API ?
--
Thanks and Regards
Sandeep
Yes you can create a template programmatically (see the REST API documentation for more info) however I want to make clear that you do not need to use a template for Embedded Signing. If you are looking at the Embedded Signing code samples in the DocuSign API Walkthroughs those use a template just to shorten the code and request body, but as mentioned it's not required.
To make any recipient an Embedded recipient (meaning they will sign using embedded signing), you simply have to set an additional property on the recipient named clientUserId. The trick is that whatever value you use for a given recipient, you have to reference that same value when requesting the signing URL.
For instance, your (partial) request body for an embedded recipient might look like this:
"recipients": {
"signers": [
{
"tabs": {
"signHereTabs": [
{
"name": "SignatureTab1",
"pageNumber": "1",
"documentId": "1",
"yPosition": "100",
"xPosition": "100"
}
]
},
"routingOrder": "1",
"recipientId": "1",
"clientUserId": "1000",
"name": "Sally Doe",
"email": "test_1#email.com"
}
]
}
Notice the clientUserId property that I've randomly set to 1000.
Now if you want to do embedded signing without a template, you can combine some of the above sample JSON with the multipart/form-data API call for creating an envelope from a local document.
This API Walkthrough shows you exactly how to do that:
http://iodocs.docusign.com/APIWalkthrough/requestSignatureFromDocument