Per the documentation one of the properties of an envelope is a boolean 'allowMarkup'. I assume this works in conjunction with the settings property located at Preferences >> Account Administration >> Features >> "Allow Markup". I have this option check and I've created a new envelope with the following json:
{
"allowMarkup": true,
"emailBlurb": "Allow Markup Test",
"emailSubject": "Test envelope that should allow to modify docs."
}
After I create the envelope I see the following check box is not checked in the UI :
It seems that i can only set the highlighted property from the UI. Bug? Can anyone reproduce this? We are testing this in sandbox as an FYI.
-mike
Just to following up on this: This was a issue was reproduced by DocuSign support and has been assigned to engineering for resolution.
Related
ERROR: Content Type specified is not supported.
Hi there, I am new to DocuSign and I am trying to learn the implementation from last couple of days. What I did so far is, created a developer account and created a QuickStart project.
Goal
I want to integrate the DocuSign API's in my application, but I don't really want the user to leave my application. I just want to make use of DocuSign within my app. - Embedded Signing
What I did?
I successfully created an envelope with a sample document and after that I have to get that URL to view (for Recipient).
So I called the below API:
** EnvelopeViews: createRecipient**
** POST - {{baseUrl}}/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}}/views/recipient**
All the details, like accountId, envelopeId are correct, along with that the request body that I pass with this is:
Request Body
{
"authenticationMethod": "none",
"clientUserId": "bcc49234-f30b-XXXX-XXXX-XXXXXXXXXXXX",
"email": "abc#gmail.com",
"recipientId": "007",
"returnUrl":"http://localhost",
"userName": "user name"
}
Note: * clientUserId is my Integration Key (please let me know if this is what I need to pass here or something else).*
Response
{
"errorCode": "INVALID_CONTENT_TYPE",
"message": "Content Type specified is not supported."
}
Note: Apart from the solution, please provide any link(s) to resources where I can easily see the implementation(as in my use case).
Umair,
First clientUserId is a bit of a confusing term, it's not the IK (Integration Key) but any string you want. It is unique to the signer and the envelope. You choose it.
You can find a detailed example of this with code in 8 languages on the DocuSign Developer Center How To Request Signature Through your app page.
I'm not clear how you make the API calls, if you are using postman, there are headers that needs to be set. One of them is called Content-Type and it has to be set to text/plain.
I just started suing DocuSign's sandbox to test some of the API call that I plan to use on my website. I was testing the call that returns the information about a particular template. I set up a template in my sandbox and emailed it to myself. I then tried to get the template info by making this call:
Envelope envInfo = envelopesApi.GetEnvelope(accountId, envelopeId);
In the JSON that I get back the value for "status" is "template", which is not one of the possible statuses according to DocuSign (https://www.docusign.com/p/RESTAPIGuide/Content/REST%20API%20References/Get%20Envelope%20Status%20Changes.htm). If anything it should be "Delivered". Has anyone had a similar issue? Thanks.
It was my own dumb error - I was checking the template ID instead of the envelope ID.
I'm using the Docusign REST APi v2 to set up docusign links for "senders" to receive links which open the docusign sender view console to place signature tags. And also to provide recipients their links to open the signing/recipient console.
We want to lock down what the senders can do as much as possible since everything the console needs will be provided to the API from our web site. We managed to go into the Docusign sandbox's preferences and munder the features menu, we disabled various tag options and custom tagging.
I have only one thing left I'd like to do; Disable the ability for the sending console to change recipient (that to/from area at the top of the console).
The users of our console only need to place the tags and hit send; we don't want them messing with the recipients themselves.
In the same features screen I disabled some features named:
Enable Send To Address Recipients
Enable Send To Manage Envelope
Enable Send To Manage Recipients
It did not have the intended effect.
Is this possible to disable this area?
You might be able to accomplish this using one of the additional recipient types such as the editor recipient.
Editors can modify tabs of an envelope and can also edit recipient information, however you can stop them from modifying the recipient name and email through additional body parameters canEditRecipientEmails and canEditRecipientNames.
Editor Recipient type from API docs.
You can use composite templates to perform the situation you described in one of your comments: 'Is there a way to create a template that's just 100% "blank: with no documents or recipients added and use that do build an envelope add a new document to that envelope?? '
Using composite templates allows you to specify a template ID and then override the underlying PDF bytes. You can create a new template and upload a blank PDF. Make sure there are no signers and then set the option to not allow editing recipients. Then specify the recipient in your JSON when creating the envelope (by the way, this is a multipart form with the boundary set to MY_BOUNDARY):
--MY_BOUNDARY
Content-Type: application/json
Content-Disposition: form-data
{
"emailSubject":"test subject",
"emailBlurb":"test blurb",
"compositeTemplates":[
{
"serverTemplates":[
{
"sequence":1,
"templateId":"<blank pdf template>"
}
],
"inlineTemplates":[
{
"sequence":1,
"recipients":{
"signers":[
{
"email":"email#domain.com",
"name":"first last",
"recipientId":"1",
"roleName":"Signer",
"clientUserId":"1"
}
]
}
}
],
"document":{
"documentId":"1",
"name":"test1.pdf"
}
}
],
"status":"created"
}
--MY_BOUNDARY
Content-Type: application/pdf
Content-Disposition: file; filename="test1.pdf"; documentId="1";
Content-Transfer-Encoding: base64
<pdf bytes>
--MY_BOUNDARY--
You can achieve this by setting below attribute at envelope level[EnvelopeDefinition.class] i.e.
#ApiModelProperty(example = "null", value = "When set to **true**, prevents senders from changing, correcting, or deleting the recipient information for the envelope.")
#JsonProperty("recipientsLock")
public String getRecipientsLock() {
return recipientsLock;
}
public void setRecipientsLock(String recipientsLock) {
this.recipientsLock = recipientsLock;
}
Is it possible to remove the Envelope Id Stamping from dev/sandbox environment? The following still results in a pdf with the envelope id. I also see no option under Preferences >> etc, etc as other posts mention to remove this. Not possible in Sandbox?
{
// extra props removed
envelopeIdStamping : false,
}
thanks,
-mike
This is an admin setting that you can reach out to DocuSign support to have them enable/disable in your account.
We are trying to set a Radio button to be selected initially when an envelope is created based on certain conditions outside of Docusign.
Testing using the following URL and request body.
https://demo.docusign.net/restapi/v2/accounts/163051/envelopes/49c4ebeb-331d-4cf9-bce7-843be646fbd5/recipients/1/tabs
Body:
{
"accountId":"163051",
"envelopeId":"49c4ebeb-331d-4cf9-bce7-843be646fbd5",
"radioGroupTabs":[
{"documentId":"1","groupName":"RadioGroup","radios":[
{"pageNumber":"2","selected":"True","tabId":"04ad92ed-377b-4389-8ec0-93999385c3f6"}
],
"recipientId":"1"}
],
"recipientId":"1"}
Even though we only have 1 radio tab, we receive this response:
{"errorCode": "INVALID_TAB_OPERATION",
"message": "The Tab specified is not valid for the requested operation. Attempt to create 'text' tab from invalid tab type."}
Why are we getting this response? We have checked and the RadioGroup, tabId, envelopeId, accountId are all valid.
Thanks for your post, looks like you've identified an api bug with the platform. In testing I've found that I can modify other tabs just fine (such as dateSigned for instance) but there seems to be a problem modifying existing radio button tabs.
I've logged a bug with DocuSign, not sure when it will be fixed though. The August release just came out so hopefully by the September release. Will post here once resolved.