Envelope Recipient not matching when requesting view - docusignapi

When creating envelopes which are used later to generate a view URL for the signer to use instead of receiving an email, we are running into a problem where the user we are specifying isn't valid.
For example, here is an envelope with one recipient, "Peter Hughes Jr."
Request URL: https://na2.docusign.net/restapi/v2/accounts/4476693/envelopes/f3a45945-f1ff-4731-a407-963a32378d77/recipients
------
{"IntegratorKey":"***","Password":"***","Username":"onboarding#impellam.com"}
Request headers:
X-DocuSign-Authentication : {"IntegratorKey":"***","Password":"***","Username":"onboarding#impellam.com"}
Host : na2.docusign.net
Connection : Keep-Alive
------
Request body:
------
Response headers:
Strict-Transport-Security : max-age=7776000; includeSubDomains
Content-Length : 696
Cache-Control : no-cache
Content-Type : application/json; charset=utf-8
Date : Thu, 18 Dec 2014 15:26:42 GMT
------
Response body:
{
"signers": [
{
"name": "Peter Hughes Jr.",
"email": "pwhughes#verizon.net",
"recipientId": "1",
"recipientIdGuid": "2461be9a-69d3-420d-b5f3-2c327af2f5f6",
"requireIdLookup": "false",
"userId": "0d5035dc-b70f-4026-8283-5c8d8903385a",
"clientUserId": "1",
"routingOrder": "1",
"note": "",
"roleName": "Applicant",
"status": "sent",
"templateLocked": "false",
"templateRequired": "false"
}
],
"agents": [],
"editors": [],
"intermediaries": [],
"carbonCopies": [],
"certifiedDeliveries": [],
"inPersonSigners": [],
"recipientCount": "1",
"currentRoutingOrder": "1"
}
When we attempt to set up a view for this user, the following exception occurs:
Request URL: https://na2.docusign.net/restapi/v2/accounts/4476693/envelopes/f3a45945-f1ff-4731-a407-963a32378d77/views/recipient
------
{"IntegratorKey":"***","Password":"***","Username":"onboarding#impellam.com"}
------
EXCEPTION
System.Net.WebException: The remote server returned an error: (400) Bad Request.
at System.Net.HttpWebRequest.GetResponse()
at DocusignView.Request.Send[T](String body) in C:\Users\johnathank\Desktop\docusigntest\DocusignView.cs:line 293
------
Request headers:
X-DocuSign-Authentication : {"IntegratorKey":"***","Password":"***","Username":"onboarding#impellam.com"}
Content-Type : application/json
Host : na2.docusign.net
Content-Length : 143
Expect : 100-continue
------
Request body:
{"authenticationMethod":"email","clientUserId":"1","email":"pwhughes#verizon.net","returnUrl":"www.impellam.com","userName":"Peter Hughes Jr."}
------
Response headers:
Strict-Transport-Security : max-age=7776000; includeSubDomains
Content-Length : 152
Cache-Control : no-cache
Content-Type : application/json; charset=utf-8
Date : Thu, 18 Dec 2014 15:28:31 GMT
------
Response body:
{
"errorCode": "UNKNOWN_ENVELOPE_RECIPIENT",
"message": "The recipient you have identified is not a valid recipient of the specified envelope."
}
We've actually identified the problem, but haven't found a good way to implement a solution yet. When inspecting the envelope within Docusign, I can see that this user has adopted the name "Peter W. Hughes Jr".
So I attempted sending another view request with the name "Peter W. Hughes Jr." instead, and it worked...
However this poses a problem. How are we able to find out what the adopted name of the user is? It is not in the original envelope data, and from browsing the API at iodocs.docusign.com, none of the methods there seem to give me the user's adopted name.
I have read an alternate solution that says we can provide a userId in the view request instead of the userName, but when I attempt to do that, I receive an error indicating that userName is required.
Request URL: https://na2.docusign.net/restapi/v2/accounts/4476693/envelopes/f3a45945-f1ff-4731-a407-963a32378d77/views/recipient
------
{"IntegratorKey":"***","Password":"***","Username":"onboarding#impellam.com"}
------
EXCEPTION
System.Net.WebException: The remote server returned an error: (400) Bad Request.
at System.Net.HttpWebRequest.GetResponse()
at DocusignView.Request.Send[T](String body) in C:\Users\johnathank\Desktop\docusigntest\DocusignView.cs:line 295
------
Request headers:
X-DocuSign-Authentication : {"IntegratorKey":"***","Password":"***","Username":"onboarding#impellam.com"}
Content-Type : application/json
Host : na2.docusign.net
Content-Length : 191
Expect : 100-continue
------
Request body:
{"authenticationMethod":"email","clientUserId":"1","email":"pwhughes#verizon.net","returnUrl":"www.impellam.com","userId":"2461be9a-69d3-420d-b5f3-2c327af2f5f6","userName":"Peter Hughes Jr."}
------
Response headers:
Strict-Transport-Security : max-age=7776000; includeSubDomains
Content-Length : 167
Cache-Control : no-cache
Content-Type : application/json; charset=utf-8
Date : Thu, 18 Dec 2014 15:52:06 GMT
------
Response body:
{
"errorCode": "INVALID_REQUEST_PARAMETER",
"message": "The request contained at least one invalid parameter. A value was not found for parameter 'userName'."
}

This is only an issue when multiple envelopes are sent in flight to the same recipient name, email and clientUserId combination.
Once you send the recipienttoken and they sign with a different name, using the same request for the second envelope will fail because of the name change.
Best practice would be to generate a new clientUserId for each envelope or prevent the recipient from changing their name within the DocuSign Account Features. The feature is called "Signature Adoption Configuration".

Related

In azure logic App how to pass Cookie to Http request

In azure logic app by calling first Http endpoint we need to get the cookie and pass to the second endpoint. But while passing second API, I am passing in header and it is sending but the response is wrong(text/html).
But When I checked by using postman it worked fine got response in JSON(application/json).
The header getting after calling second API or endpoint through logic app ,I am getting is:
{
"statusCode": 200,
"headers": {
"Cache-Control": "no-store, must-revalidate, no-cache",
"X-Powered-By": "Undertow/1",
"Set-Cookie": "JSESSIONID=Ntu9NMCoekk56JveKceina3FCwgNJptU4EK0GOIz.s192-169-141-210; path=/StLightControl",
"Server": "WildFly/10",
"Pragma": "no-cache,no-cache",
"Date": "Tue, 12 Jun 2018 14:25:45 GMT",
"Connection": "keep-alive",
"Content-Length": "2585",
"Expires": "0,0",
"Content-Type": "text/html; charset=UTF-8"
}
}
The “Add new parameter” dropdown allows you to enable a checkbox that says “Cookie” that enables you to enter the HTTP cookie (from dynamic content if you want to). You cannot enter the value straight in the dropdown, so close it down after you selected the checkbox and see a magic Cookie field appear underneath the Authentication field.
More information to be found here: HowTo: Call an API with cookie authentication from a Logic App

Docusign API: Template roles not being merged

When creating an envelope using a template, the recipient data is not merging with the role defined in the template despite having the same role name. Instead, the data defined in the request is sent in addition to the default template role. Here is the request being sent:
{
"emailSubject":"Example Email",
"status":"created",
"templateId":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"templateRoles":[
{
"email":"john.doe#gmail.com",
"name":"John Doe",
"roleName":"role_01"
}
]
}
When I examine the draft saved in the app demo, there are now 2 recipients on the envelope: John Doe and the placeholder in the template. Despite having the same role name, John Doe does not inherit any of the template tabs for 'role_01'.
This request was made using Docusign's PHP SDK.
EDIT:
Here is the request logged in DocuSign:
POST https://demo.docusign.net:7802/restapi/v2/accounts/[omitted]/envelopes
TraceToken: 273fe6c7-ac95-46b5-8c04-27fb91b6b9a4
Timestamp: 2018-04-04T16:43:42.6317470Z
Content-Length: 221
Content-Type: application/json
Accept: application/json
Host: demo.docusign.net
User-Agent: Swagger-Codegen/2.0.1/php
X-DocuSign-Authentication: {"Username":"56eeb1f9-b9ae-40b1-94f7-5fff2ed2a67f","Password":"[omitted]","IntegratorKey":"[omitted]"}
X-DocuSign-SDK: PHP
X-SecurityProtocol-Version: TLSv1.2
X-SecurityProtocol-CipherSuite: ECDHE-RSA-AES256-GCM-SHA384
x-forwarded-for: 70.234.88.244
{"emailSubject":"Please Sign","status":"created","templateId":"a0e38e1b-a8af-4ce9-9398-cc1bb4bbb5d3","templateRoles":[{"email":"john.doe#gmail.com","name":"John Doe","roleName":"role_01"}]}
201 Created
Content-Type: application/json; charset=utf-8
X-DocuSign-TraceToken: 273fe6c7-ac95-46b5-8c04-27fb91b6b9a4
{
"envelopeId": "e6a04bb7-f73f-4f22-84a5-b3d4e8ce1fea",
"uri": "/envelopes/e6a04bb7-f73f-4f22-84a5-b3d4e8ce1fea",
"statusDateTime": "2018-04-04T16:43:42.2270000Z",
"status": "created"
}
You should not be having Name and Email already present in the template. I think you have FirstName LastName, example#email.com in the template name, email respectively. Delete these values in the template, template should only have roleName.

Is it possible to retrieve entered tag values from a signed DocuSign document

I am using the DocuSign REST API to created an embedded signing for a predefined document template using the /envelopes/{envelopeID}/views/recipient call. I know it is possible to pre-populate tag values when creating the envelope, but is it possible to retrieve the value the recipient actually provides in a given tag field for use in the application after signing is complete? If so, does anyone have an example?
Sounds like you are trying to Get Envelope Recipient Status with the optional query include_tabs
https://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf page 133
Example Request
GET https://{server}/restapi/{apiVersion}/accounts/{accountId}/envelopes/{envelopeId
}/recipients/?include_tabs=true
X-DocuSign-Authentication:
<DocuSignCredentials><Username>{name}</Username><Password>{password}</Password><Integrato
rKey>{integrator_key}</IntegratorKey></DocuSignCredentials>
Accept: application/json
Content-Type: application/json
Response
The response returns the recipient types and current routing order. The recipient types includes the
recipient name, email, ID, recipient type, routing order, authentication status (including the date/time
and result of the authentication) status (including the date/time of the status changes) and, if the
recipient status is declined and a reason is required, a decline reason added by the recipient.If the
optional query include_tabs is set to true, the
tabs associated with the recipient are returned.
The following example shows the response json body
Example Response
{
"signers": [
{
"tabs": {
"textTabs": [
{
"height": 11,
"name": "Text",
"value": "this is a test",
"width": 66,
"required": "false",
"locked": "false",
"disableAutoSize": "false",
"tabLabel": "TAB1",
"documentId": "1",
"recipientId": "ed0e8744-6243-4708-9186-0e3ccf4cb3a4",
"pageNumber": "1",
"xPosition": "93",
"yPosition": "142",
"tabId": "2c7b4d94-d958-44df-b5a7-2b530ce914ed"
}
Yes there are at least a couple of ways to retrieve tab values from the signed (completed) docs. I believe Justin's answer is one way. You can also use the Get Tab Information for a Recipient API call, which will return tabs information (values included):
URL:
/accounts/{accountId}/envelopes/{envelopeId}/recipients/{recipientId}/tabs
Method:
GET
Example from DocuSign API Docs:
GET https://{server}/restapi/{apiVersion}/accounts/{accountId}/envelopes/{envelopeId}/recipients/{recipientId}/tabs
X-DocuSign-Authentication: <DocuSignCredentials><Username>{name}</Username><Password>{password}</Password><IntegratorKey>{integrator_key}</IntegratorKey></DocuSignCredentials>
Accept: application/json
Content-Type: application/json
Sample Response:
{
"approveTabs":[{
<Tab information removed>
}],
"textTabs":[{
<Tab information removed>
}],
"signHereTabs":[{
...
}]
}

Docusign : Unable to create envelope from document in restapi v2

We are trying to create an envelope from a pdf document using the docusign restapi v2. We can create an envelope using XML but when we try using JSON we receive the following error from docusign.
"errorCode": "ENVELOPE_IS_INCOMPLETE",
"message": "The Envelope is not Complete. A Complete Envelope Requires Documents, Recipients, Tabs, and a Subject Line. Envelope definition missing."
The entire POST we are sending is below from fiddler (with the file content removed).
POST https://demo.docusign.net/restapi/v2/accounts/xxxxx/envelopes HTTP/1.1
X-DocuSign-Authentication: {"Username":"xxxxxx","Password":"xxxxx","IntegratorKey":"xxxxxx"}
Content-Type: multipart/form-data; boundary=AAA
Accept: application/json
Host: demo.docusign.net
Content-Length: 90500
Expect: 100-continue
--AAA
Content-Type: application/json
Content-Disposition: form-data
{
"emailBlurb": "Blurb",
"emailSubject": "Subhject",
"documents": [
{
"name": "NDA.pdf",
"documentId": "1"
}
],
"recipients": {
"signers": [
{
"tabs": {
"signHereTabs": [
{
"pageNumber": "1",
"yPosition": "1",
"xPosition": "1",
"documentId": "1",
"tabId": "1",
"name": "TabName"
}
]
},
"routingOrder": "1",
"recipientId": "1",
"name": "Ben",
"email": "ben#test.com"
}
]
},
"status": "created"
}
--AAA
Content-Type: application/pdf
Content-Disposition: file; filename="NDA.pdf"; documentId="1"
<pdf file image content goes here>
--AAA--
As far as I can tell the JSON looks correct. Is there anything wrong that we are missing here?
Your JSON looks ok, this might be due to you having an extra CRLF character or two separating your boundaries in your request body. In general this is how things need to be spaced out (each newline is a \r\n):
--AAA
Content-Type: application/json
Content-Disposition: form-data
<YOUR VALID JSON GOES HERE>
--AAA
Content-Type:application/pdf
Content-Disposition: file; filename="document.pdf"; documentid=1
<DOCUMENT BYTES GO HERE>
--AAA--
It's quite possible that extra newline you have after your document bytes is causing your issue.
I had the same problem symptoms.
My problem was with the "Boundary terminator". Be sure to use:
--AAA
Content-Type: application/json
Content-Disposition: form-data
<YOUR VALID JSON GOES HERE>
--AAA--
if you have no document in your multipart attachement

Use update handler for document delete

I need to delete a document from CouchDB, but first I need to check if a condition is met. The first thing that comes to mind is using an update handler instead, iterating manually over all keys in the update handler and deleting those without a _ prefix and setting the _delete field to true.
I guess this should produce the same result as a normal DELETE, am I right?
Update:
Using #Kxepal's suggestion, this is what the update handler looks like:
function (doc, req) {
if (req.query.account_id != doc.account_id) {
return [doc, '{"error": "invalid account id"}'];
}
return [{
_id: doc._id,
_rev: doc._rev,
_deleted: true
}, 'ok'];
}
Not really.
When you DELETE document, CouchDB removes any fields from it except _id and _rev (sure, _deleted is also there). This information is also known as tombstone.
When you just adds _deleted: true to document, it becomes marked as deleted, but all other fields are still there:
http --json http://localhost:5984/recipes/SpaghettiWithMeatballs:
HTTP/1.1 404 Object Not Found
Cache-Control: must-revalidate
Content-Length: 41
Content-Type: application/json
Date: Sat, 17 Aug 2013 14:49:17 GMT
Server: CouchDB/1.4.0+build.c843cef (Erlang OTP/R16B)
{
"error": "not_found",
"reason": "deleted"
}
http --json http://localhost:5984/recipes/SpaghettiWithMeatballs\?rev\=9-ac84157c2206793b7d142f5d8e2c97d0:
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 425
Content-Type: application/json
Date: Sat, 17 Aug 2013 14:48:55 GMT
ETag: "9-ac84157c2206793b7d142f5d8e2c97d0"
Server: CouchDB/1.4.0+build.c843cef (Erlang OTP/R16B)
{
"_attachments": {
"my_recipe.txt": {
"content_type": "text/plain",
"digest": "md5-198BPPNiT5fqlLxoYYbjBA==",
"length": 85,
"revpos": 2,
"stub": true
}
},
"_deleted": true,
"_id": "SpaghettiWithMeatballs",
"_rev": "9-ac84157c2206793b7d142f5d8e2c97d0",
"description": "An Italian-American dish that usually consists of spaghetti, tomato sauce and meatballs.",
"ingredients": [
"spaghetti",
"tomato sauce",
"meatballs"
],
"name": "Spaghetti with meatballs"
}
However, during compaction, this document will be converted to tombstone with only _id, _rev and _deleted fields. Until then, this is good trick to keep data within document to easily undo delete operation without requesting document's previous revision since all content available for the latest one.

Resources