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.
Related
I've been working on a function that puts a value in a list column if it exists. However, in the case that it doesn't exist (which I check using GET https://graph.microsoft.com/v1.0/drives/{driveID}/list/columns"), I'd like it to make a list column. How do I create a new column in SharePoint using Microsoft Graph's REST API? I've scoured the documentation but have thus far come up short.
Per the API documents, there is no such an endpoint to update a list. I believe the related functionality has not been released. You can submit the feedback on Microsoft Graph Feature Requests or turn to the old sharepoint rest api:
https://www.codesharepoint.com/rest-api/create-list-column-in-sharepoint-using-rest-api
HTTP :
POST https://graph.microsoft.com/v1.0/me/drive/items/{id}/workbook/tables/{id|name}/columns
Content-type: application/json
Content-length: 81
{
"id": 99,
"name": "name-value",
"index": 99,
"values": "values-value"
}
Response : HTTP
HTTP/1.1 201 Created
Content-type: application/json
Content-length: 81
{
"id": 99,
"name": "name-value",
"index": 99,
"values": "values-value"
}
Response :
If successful, this method returns 201 Created response code and WorkbookTableColumn object in the response body.
For more details : https://learn.microsoft.com/en-us/graph/api/table-post-columns?view=graph-rest-1.0&tabs=http
I have a small logic app which is meant to fetch data from somewhere and store it on blob. I then would like to send the URL to all devices via push notification. I wish to send the URL as a raw notification, so on the app/background task, i can do some processiong.
The problem is when i use logic app to create a http POST request to send a notification, i get a 400 error. The same header with authentication and etc, with the payload and URL works fine on a POSTMAN or REST API CLIENT. THe following are the inputs and outputs. Please help. Brain dead already.
This is the input.
{
"uri": "https://xxoppoc.servicebus.windows.net/xxopPOC/messages/?api-version=2015-01",
"method": "POST",
"headers": {
"Authorization": "SharedAccessSignature sr=sb%3a%2f%2fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxt%2f&sig=qEnxxxxxxxxxxxx&skn=DefaultFullSharedAccessSignature",
"Content-Type": "application/octet-stream",
"ServiceBusNotification-Format": "windows",
"ServiceBusNotification-Tags": "MyTag",
"X-WNS-Type": "wns/raw"
},
"body": "Some Raw Information. Hello World"
}
This is the output:
{
"statusCode": 400,
"headers": {
"transfer-Encoding": "chunked",
"date": "Wed, 30 Mar 2016 14:10:41 GMT",
"server": "Microsoft-HTTPAPI/2.0"
},
"body": {
"$content-type": "application/xml; charset=utf-8",
"$content": "PEVycm9yPjxDb2RlPjQwMDwvQ29kZT48RGV0YWlsPlRoZSBjb250ZW50IHR5cGUgZm9yIGEgJ3ducy9yYXcnIG5vdGlmaWNhdGlvbiBtdXN0IGJlICdhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW0nLlRyYWNraW5nSWQ6NTNmNjhlMGItNDc1MC00ZDRkLWJiNTAtMzJjNTBmOGIyNDk1X0czLFRpbWVTdGFtcDozLzMwLzIwMTYgMjoxMDo0MSBQTTwvRGV0YWlsPjwvRXJyb3I+"
}
}
Let me mention again, I got the authentication correct as it works on Advanced REST Client on chrome and POSTMAN. The above logic app also works if i send a wns/toast notification with xml as its content-type. I however need it to be a wns/raw notification. Please help. Thank you
EDIT/PROGRESS
Thanks to MichaelB, We figured out that the content-type is being modified. I sent the request to a different URL to look at the header. The following was observed:
Content-Type: application/octet-stream; charset=utf-8
If I use the above Content-Type on POSTMAN. It actually fails as well. So this could be 1 step. Why is Azure Logic Apps adding charset-utf-8 to the end of my content type. Can I stop it?
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".
I am trying to use OAuth client_credentials with Windows Microsoft Azure. I can successfully generate an access_token but get when I try and access https://graph.windows.net/mydomain.com/users?api-version=2013-04-05 I get 403 Forbidden.
What am I doing wrong? I think I'm not requestion a sufficiently authorized access_token but I cannot find/guess other resource or params to add.
My current flow
Request
> POST /mydomain.com/oauth2/token HTTP/1.1
> Host: login.windows.net
> Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&client_id={client_id}
&client_secret={client_secret}
&resource=https://graph.windows.net
Response
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
{
"access_token": "<string>",
"token_type": "Bearer",
"expires_in": "<seconds>",
"expires_on": "<timestamp>",
"resource": "https://graph.windows.net"
}
Request
> GET /mydomain.com/users
> ?api-version=2013-04-05 HTTP/1.1
> Host: graph.windows.net
> Authorization: Bearer {access_token}
Response
< HTTP/1.1 403 Forbidden
{
"odata.error": {
"code": "Authorization_RequestDenied",
"message": {
"lang": "en",
"value": "Insufficient privileges to complete the operation."
}
}
}
Note: I get 403 Unauthorized if I miss out or mess with the {access_token}.
Per my comment, you need to make sure that you've selected the proper permissions from the "permissions to other applications" drop-down in the portal, otherwise access won't be granted. See this page in the documentation for more information.
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