I have a pretty basic question about how the Docusign API works. I tried finding the answer myself but was quickly overwhelmed by the massive amount of information, much of which is outdated, in the support center.
Here’s what I’m trying to do:
I have uploaded and configured multiple templates in my Docusign account
I am writing a web app which will allow my users to request a subset of those templates based on certain criteria
The subset of templates would then be used in my app via an iframe integration (I'm assuming)
I would also like to automatically populate several of the fields in my new copies of the templates
How do I perform the API request in step 2?
How do I perform the API call in step 3? Or are the values injected into the document some other way?
A totally different approach would be to provision a new Docusign account for each of my users but that didn’t seem right. If someone could just point me in there right direction I would really appreciate it.
It's actually not that basic of a question, I'd say if you were asking how to send a signature request on a document or from one template that's basic but how to combine and send multiple templates and populate values in them is a little more involved.
With that said, to combine multiple templates into signature requests you can simply use the Composite Templates node in your envelope definition. Using composite templates you can combine multiple server-side templates from your account, or combine templates with local documents or documents from other sources (i.e. cloud).
Regarding your Questions:
1]
You can make an API call to programmatically retrieve the templates that are available in your account then display whatever aspects you want about them in your UI, such as name, description, template ID, etc. Once the user (or your app logic) indicates which templates they want to combine into a signature request you can combine them like this (this combines 2 server templates):
{
"emailSubject":"DocuSign Signature Request using Composite Templates",
"status":"sent",
"compositeTemplates":[
{
"serverTemplates":[
{
"sequence":"1",
"templateId":"55A80182-2E9F-435D-9B16-FD1E1C0F9D74"
}
],
"inlineTemplates":[
{
"sequence":"1",
"recipients":{
"signers":[
{
"name":"John Doe",
"email":"firstrecipient#gmail.com",
"recipientId":"1",
"clientUserId":"1001",
"roleName":"RoleOne"
}
]
}
}
]
},
{
"serverTemplates":[
{
"sequence":"2",
"templateId":"44D9E888-3D86-4186-8EE9-7071BC87A0DA"
}
],
"inlineTemplates":[
{
"sequence":"2",
"recipients":{
"signers":[
{
"name":"Jane Doe",
"email":"secondrecipient#gmail.com",
"recipientId":"1",
"clientUserId":"1002",
"roleName":"RoleOne"
}
]
}
}
]
}
]
}
2]
Yes if you want to embed your recipients (which means they sign through your UI and not through the DocuSign website or app) then it is recommended you use an iFrame for Web apps and a Webview for mobile apps. To embed a given recipient you must set their clientUserId as I have for both recipients in the above example. This is a string and is defined on the client-side, you just need to remember which values you use for each recipient as you need that to generate each recipient's signing URL (which you will load in the iFrame).
Have a look at the "Signing from within your app" API Recipe for sample code of how to accomplish this. That sample doesn't use templates to create the envelope but it shows how to generate the unique signing URLs:
Signing from within your app
Or if you want to test with raw API calls (that don't use the DocuSign SDKs) you can use the API Explorer to test these calls:
API Explorer
3]
You basically had a third question I think which was how to populate the tabs (aka document fields) in the template. You can identify a given tab by its tabLabel and populate it's value using the value property. For instance, if you had two tabs of type textTab (called Data fields in the UI) you can populate their values like this:
{
"email": "jane.doe#email.com",
"name": "Jane Doe",
"roleName": "RoleOne",
"recipientId": "1",
"clientUserId": "1001",
"tabs": {
"textTabs": [
{
"tabLabel": "ApplicantAddress",
"value": "221 Main St. Suite 1000 San Francisco, CA 94105"
},
{
"tabLabel": "ApplicantSSN",
"value": "12-345-6789"
}
]
}
}
Related
We are sending the document from our app to DocuSign, and we want to add checkboxes at a specific position. How do we achieve this using API endpoint?
I tried adding checkbox manually on docusign portal now I want to check if can I achieve it by using API endpoint. I searched inside docusign API but didn't get any specific API for the same.
xPosition and yPosituon properties on the object can be used to position any tab including checkbooks.
JSON:
checkboxTabs": [
{
"tabLabel" : "myCheckbox",
"xPosition": "50",
"yPosition": "50",
"tabGroupLabels": [
"checkboxgroup1"
],
}
]
More information about checkbooks:
https://www.docusign.com/blog/developers/tabs-deep-dive-checkboxes-and-radio-groups
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 need to get accurate inventory numbers via the Acumatica API so that I can update inventory on an external site. Our only method of getting accurate inventory is running a report under Distribution -> Inventory -> Reports Tab then selecting Inventory Balance and running the report without an Inventory ID so I get a full list of all inventory in our system. How can I run this report (or any report) via Acumatica's API? I can use REST or SOAP in this case.
I need the data from the report in a manner that I can consume it in my C# application and use it to update a database on an external site. So for example, if I were using the REST API, I would want a report returned in JSON format. Example desired return below:
{
"InventoryID": {
"value": "CW-500-MC-30"
},
"Warehouse": {
"value": "WH1"
},
"Description": {
"value": "Milk chocolate chews"
},
"Available": {
"value": 8
}
},
{
"InventoryID": {
"value": "AB-100-SE-30"
},
"Warehouse": {
"value": "WH1"
},
"Description": {
"value": "Face lotion"
},
"Available": {
"value": 12
}
}
As mentioned in the Appendix of the I210 course pdf section Generate a printable invoice by invoice ID :
This web integration scenario is not supported in the available versions of system endpoints. If you need to generate reports, you can use the screen-based SOAP API. For details, see the I200 Screen-Based Web Services training course in Acumatica University.
Looking in that course and following the Example 4.3.3: Generating the Printable Version of an Invoice will show how to get a report through the API.
Which can be resumed by putting the following information in the command list sent through the API.
The different parameters that need to be set for the report
A mention to the PDF Content from the Report Result so that the API knows that must return it to you.
After that you only need to use any library capable of writing to your file system in order to create the PDF file with the information you just received.
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.