Phone Identity with Docusign - docusignapi

I'm looking to build some C# desktop client application that will send out a large number of PDF to sign to a large number of different individual so I'm wondering if the docusign API provide access to automate the Phone identity feature? I was not able to find out the page on their site.

Yes you can access this through the api, the DocuSign Developer Center has pages on the more prevalent features, for full information always check the documentation:
DocuSign API Documentation
You can add a recipient parameter in your request body that sets the idCheckConfigurationName which can be used for an RSA ID check or SMS authentication, and there's also a phoneAuthentication setting which I believe is what you are looking for. The JSON would look something like:
"recipients": {
"signers": [{
"idCheckConfigurationName": "string1",
"phoneAuthentication": "string2"
}]
}
where string1 could be ID Check $ for an RSA ID Check or SMS Auth $ for SMS auth for instance, and string2 is actually made up of a boolean and a list which are used to configure the phone authentication. Please see DocuSign's documentation for more info.

To specify phone authentication for a recipient, you need to specify the following properties for the recipient in the Create Envelope request:
"idCheckConfigurationName": "Phone Auth $",
"requireIdLookup": "true",
"phoneAuthentication": {
"recipMayProvideNumber": "false",
"senderProvidedNumbers": [
"206-222-1111"
]
}
For example, here's a Create Envelope request that specifies phone authentication for the first (and only) recipient.
POST https://{{env}}.docusign.net/restapi/{{version}}/accounts/{{acctId}}/envelopes
{
"status" : "sent",
"emailBlurb":"Test Email Body",
"emailSubject": "-- Test Email Subject --",
"recipients": {
"signers" : [
{
"email": "bobsemail#outlook.com",
"name": "Bob Adamson",
"idCheckConfigurationName": "Phone Auth $",
"requireIdLookup": "true",
"phoneAuthentication": {
"recipMayProvideNumber": "false",
"senderProvidedNumbers": [
"206-111-2222"
]
},
"recipientId": "1",
"routingOrder": "1",
"tabs": {
"signHereTabs": [
{
"recipientId": "1",
"tabLabel": "Customer_Signature",
"documentId": "1",
"pageNumber": "1",
"xPosition": "99",
"yPosition": "424"
}],
"dateSignedTabs": [
{
"recipientId": "1",
"tabLabel": "Customer_Date",
"documentId": "1",
"pageNumber": "1",
"xPosition": "373",
"yPosition": "456"
}]
}
}]
},
"documents": [
{
"name": "TestDocAPI.pdf",
"documentId": 1,
"documentBase64": "BASE_64_ENCODED_DOCUMENT_BYTE_STREAM"
}]
}
This is just one example -- the properties you set under the phoneAuthentication object may differ depending on your specific requirements. See the DocuSign REST API Guide (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf) for information about additional properties available under phoneAuthentication.

Related

Docusign: How does one send SMS and email signature requests for the same recipient?

How do I create a recipient with both email and SMS?
I've been unable to find example JSON that addresses this issue. The documentation on Docusign's website shows either email or SMS, not both together (that I can find, anyway). I found a note somewhere that suggested it's possible, but I can't find it again.
If your account has SMS Delivery enabled, you can make an API Request in the following format to send an envelope with Email + SMS Delivery
{
"documents": [
{
"documentBase64": "Base 64 here",
"documentId": 1,
"fileExtension": "txt",
"name": "Filename"
}
],
"emailSubject": "Blurb",
"recipients": {
"signers": [
{
"email": "Recipient Email Here",
"name": "DocuSigner",
"recipientId": "1",
"tabs": {
"signHereTabs": [
{
"xPosition": "10",
"yPosition": "10"
}
]
},
"additionalNotifications": [
{
"secondaryDeliveryMethod": "SMS",
"phoneNumber": {
"countryCode": "Code",
"number": "Phone number"
}
}
]
}
]
},
"status": "sent"
}

How to handle documents for view only in Docusign

This is with the REST api. I have some documents which only need to be viewed, they have no anchor text tags on them. I found that if I gave such documents a server template id, that Docusign would use whichever document was part of the template and not the one I specified. Is the best practice to use certified viewers for such documents and not have them be signers? I noticed that if I had a server template and at least one of my documents had signing tabs, that all the other documents that I wanted to view would be viewable.
Yes, best practice here would be to use a different recipient type other than signer. The certified delivery recipient should work, the carbon copy (cc) recipients should also work well in this case.
Here's what a request with a Carbon Copy recipient in routing order 2 looks like:
{
"emailSubject": "Please sign this doc",
"status": "sent",
"documents": [
{
"documentId": "1",
"name": "test.pdf"
}
],
"recipients": {
"signers": [
{
"email": "signer#email.com",
"name": "John Doe",
"recipientId": "1",
"routingOrder": "1",
"tabs": {
"signHereTabs": [
{
"xPosition": "100",
"yPosition": "100",
"documentId": "1",
"pageNumber": "1"
}
]
}
}
],
"carbonCopies": [
{
"email": "carbonCopy#email.com",
"name": "Sally Doe",
"recipientId": "2",
"routingOrder": "2"
}
]
}
}

DocuSign Embeded API Instant Sign Without Authentication from DocuSign

I need to create an application where user could sign the document on my website without any docusign authentication I guess just like LoanCo Sample Demo.
I'm using Embedded Signing and following the steps listed here, and getting the URI on EnvelopeViews: createRecipient call, but when I'm trying to access that URI it redirect to "/Signing/SessionTimeout.aspx" and says "SESSION ENDED" and then nothing happens, attaching the snapshot of "session ended" page.
Here is the create envelopes request JSON.
{
"documents": [
{
"documentBase64": "<Base64BytesHere>",
"documentId": "1",
"fileExtension": "pdf",
"name": "PDF Doc"
}
],
"emailSubject": "Doc Sign",
"recipients": {
"signers": [
{
"clientUserId": "clientUserId",
"email": "examble#email.com",
"name": "Shah",
"recipientId": "1",
"tabs": {
"signHereTabs": [
{
"documentId": "1",
"pageNumber": "1",
"tabLabel": "Sign Here",
"xPosition": "100",
"yPosition": "100"
}
]
}
}
]
}
}
Here is my createRecipient request JSON.
{
"authenticationMethod": "email",
"email": "examle#email.com",
"returnUrl": "https://localhost/index.php",
"userName": "Shah"
}
After the envelope is created, use the createRecipient:EnvelopeViews api to retrieve the Signing URL.
In your request you are missing the clientUserId parameter.
Request
{
"userName": "Shah",
"email": "examble#email.com",
"clientUserId": "clientUserId",
"authenticationMethod": "email",
"returnUrl": "https://localhost/index.php"
}

Authentication for an "Editor" is not taken into account

In my DocuSign integration, I have successfully been able to set up authentication for any signer. I am now trying to set it up for the Editor of the package. While my Editor receives the signing email, when he clicks on the link to proceed to the signing ceremony, the authentication doesn't seem to work and instead of having to verify his identity, the document is displayed and ready to sign.
Is it a feature or a bug ? I was thinking maybe since the editor has to have a DocuSign account, hence any authentication is unnecessary ?
My JSON code below :
{
"name": "John Doe",
"email": "John.Doe#mailinator.com",
"recipientId": "2",
"requireIdLookup": "True",
"idCheckConfigurationName": "ID Check $",
"customFields": [
"PARTY-8"
]
}
Editor should be prompted for ID check during the signing ceremony, if it was setup correctly during sending.
Here is a sample CreateEnvelope call for setting up Id check for the Editor. I have tried this in the Docusign Demo environment and it works fine for me.
{
"recipients": {
"editors": [
{
"name": "john smith",
"email": "johnsmith#foo.com",
"recipientId": "1",
"routingOrder": "1",
"requireIdLookup": "true",
"idCheckConfigurationName": "ID Check $"
}
]
},
"documents": [
{
"documentId": "1",
"name": "Agreememt",
"fileExtension": "pdf",
"documentBase64": "[Document bytes go here]"
}
],
"status": "sent",
"emailSubject": "Envelope with id check enabled for Editore"
}

Signers vs Recipients

We are integrating our BPM application with Docusign. We have a document which should be signed by n individuals. Should we have multiple recipient tags or just 1 recipient tag with multiple signer tags inside that? What would be the difference between both the approaches?
Each Recipient object has properties that identify a specific signer including a property that represents the signer's name, for example). Your "Create Envelope" API request will need to include a separate Recipient object for each Signer -- and then, for each recipient, you'll specify tags that belong to the recipient. (The other approach you describe -- i.e., facilitating multiple people signing an envelope by specifying only one recipient with multiple 'sign here' tags -- is not feasible under any circumstances.)
For example, the recipients structure that represents two Signers, each having one place to sign and one text box to complete, would look something like this:
"recipients": {
"signers": [
{
"name": "John Doe",
"email": "johnsemail#outlook.com",
"recipientId": "1",
"routingOrder": "1",
"clientUserId": "123",
"tabs":{
"signHereTabs":[
{
"tabLabel":"BSign1",
"documentId": "1",
"pageNumber": "1",
"xPosition": "200",
"yPosition": "200"
}
],
"textTabs":[
{
"tabLabel":"BorrowerPhone",
"value":"717-717-7171",
"documentId": "1",
"pageNumber": "1",
"xPosition": "100",
"yPosition": "100"
}
]
}
},
{
"name": "Jane Doe",
"email": "janesemail#outlook.com",
"recipientId": "2",
"routingOrder": "2",
"clientUserId": "567",
"tabs":{
"signHereTabs":[
{
"tabLabel":"CBSign1",
"documentId": "1",
"pageNumber": "2",
"xPosition": "200",
"yPosition": "200"
}
],
"textTabs":[
{
"tabLabel":"Co-BorrowerPhone",
"value":"111-222-3333",
"documentId": "1",
"pageNumber": "2",
"xPosition": "100",
"yPosition": "100"
}
]
}
}
]
}
Taking some time to review the information (and code samples) on the DocuSign Developer Center (https://www.docusign.com/developer-center) and within the REST API Guide (https://10226ec94e53f4ca538f-0035e62ac0d194a46695a3b225d72cc8.ssl.cf2.rackcdn.com/rest-api-guide-v2.pdf) would be time well spent.

Resources