|
Welcome to a very packed developer newsletter! This month we have many new updates, events and information for you. We are happy to announce new releases of all our SDKs, including the Native iOS SDK. We also have added four new code examples in six programming languages. Furthermore, we recently updated our sample app, LoanCo, which you can find in the Developer Center. Coming in November are some exciting developer events, including Dreamforce, where our team will be demonstrating the DocuSign APIs. And finally, we’ve got new posts about how to use our Sign on Paper feature and how to add DocuSign Connect webhooks to your application. Hold on tight, there’s a lot to go through...
Have a topic you’d like to see covered in this newsletter? Take our short survey and share your thoughts!
|
Thanks for reading,
|
 |
Lead Developer Content Manager |
|
|
|
|
DocuSign at Dreamforce 2019
DocuSign’s API team will be returning to Trailhead for Dreamforce 2019. Take hands-on courses and learn best practices during our technical sessions. Stop by our booth to earn swag and get tips on how to build your DocuSign integrations. Learn all about our Apex Toolkit, a set of predefined Apex methods and classes that encapsulates DocuSign eSignature API functionality (similar to an SDK).
|
|
|
All DocuSign eSignature SDKs now support the DocuSign eSignature REST API v2.1
DocuSign’s latest released versions of its SDKs now all support the latest version of our eSignature REST API, version 2.1. Check this post for the latest version numbers for both v2.0 and v2.1 of our API, and get links to the downloadable packages as well as the source code on GitHub.
|
|
|
|
LoanCo Sample App: Revived!
|
|
DocuSign eSignature Native iOS SDK Version 2.2 Released
DocuSign has released an update for its Native iOS SDK! The new version 2.2 is built with XCode 11.1 and supports iOS 13 and iPadOS. It also handles Dark Mode and includes a fix for a signature adoption issue. You can read more about it on the DocuSign Developer Blog or view the Changelog for details.
|
|
|
Four New eSignature Code Examples Are Now Available
|
|
|
Common API Tasks🐈: Add a Connect Webhook to your Envelopes
Lead Developer Content Manager Inbar Gazit shows you how to set a custom webhook to communicate with DocuSign Connect, our webhook service. Using DocuSign Connect, you can eliminate polling and save a lot of processing cycles by enabling DocuSign Connect to automatically notify your application of status changes. Read the Developer Blog post for more.
|
|
|
Deep Dive Discussions: DocuSign Engineering’s Olive Design System
DocuSign’s Developer Evangelism Director, Caly Moss, sits down with Joe Cocco, Senior Software Engineering Manager and the brains behind Olive, DocuSign’s homegrown UI design system used across our products. The Olive system standardizes DocuSign’s UI components and supports both Angular and React. Watch the interview and get an inside look!
|
|
|
Developer Spotlight
Brady Root
 Brady Root got his start in tech in 2013 with an Associate’s degree in Computer Networking from Bellingham Technical College in Washington state. Shortly before graduating, he was offered an IT/Help Desk internship at a software company in town, which turned into a job after he received his degree. This was followed by a position as a technician for an outsourced IT shop before he and his wife moved to Texas, where he now works for the Foundation for Trusted Identity, a nonprofit dedicated to increasing adoption of federally certified strong identification credentials. In that position he’s grown from IT support to development and now manages the organization’s web infrastructure. FTI provides PIV-I cards and other federally cross-certified credentials to entities like state and local governments. To do so, they remotely onboard clients from all across the country. Having them print, sign, scan, and upload was tedious and time-consuming, so Brady and his team decided to integrate DocuSign embedded signing into their onboarding portal and processes. On the FTI onboarding portal, customers input their information (email, name, title, and so on), which is used to populate fields on an agreement in an envelope using a template Brady’s team created in DocuSign. On a specific button click, the envelope is generated and displayed to the customer. This is done by sending an AJAX request with the appropriate information to the DocuSign eSignature REST API, including a JWT token generated by FTI. If different signers or roles are necessary for a given document, the other parties are emailed a link that will bring them to an embedded signing page on the FTI site as well. When the appropriate customers have signed, FTI personnel are notified to do the final signing using the DocuSign Connect notification service, which sends all the necessary documents and signing info to the FTI API. Once a document is signed by all parties, DocuSign Connect is then leveraged again to send the final document’s PDF data back to FTI. Brady is currently working on a bachelor’s degree, which he plans to finish next year. In their spare time, he and his wife take hikes and bike rides and enjoy watching Spurs games with their dog. ;-) You can reach Brady at brady.root@fti.org or find him on LinkedIn.
|
|
Release Notes Roundup
November 2019 Release Notes
Release type — Monthly release Release date — October 18, 2019 Platform(s) affected — Demo (Sandbox) Release notes detail — Click hereSummary:
- New ID Verification setting — Admins can now require or disable the need for repeating the identification process once a recipient’s role is completed.
- Terminology updates — Several significant changes in terminology have been implemented in DocuSign Admin and in Org Admin.
- Various bug fixes
|
|
October 2019 Release Notes
Release type — Monthly release Release date — October 4, 2019 Platform(s) affected — Production Release notes detail — Click hereSummary:
- New activation experience — Recipients who do not have a DocuSign account will be able to activate their account and sign their envelope all at once through the same email.
- Legacy Single Sign-On deprecated — DocuSign has deprecated support for the legacy Single Sign-On (SSO) v1 platform. All legacy SSO v1 configurations have been permanently removed.
- Create Recipient View return URL changed — The URL will be longer, as customers are redirected through a regional subdomain corresponding to the region of the account sending the envelope. The change is part of an effort to improve security.
|
|
From the Trenches
Sign on Paper
While in general, it’s recommended to use DocuSign fully electronically, there are cases where it is preferred, or even necessary, to have a recipient sign a physical copy. In these cases, "Print and Sign" (WetSign in the eSignature API) can be used. If you’re not familiar with the process, Support documentation is available. To control whether this feature is enabled for a particular envelope, set the EnableWetSign parameter in the EnvelopeDefinition object. Note that what is set in the API overrules what is set on the account’s Signing Settings. In C#, setting an envelope to allow this looks like:
var envelopeDefinition = new EnvelopeDefinition
{
EnableWetSign = "true",
EmailSubject = "WetSign Example Envelope",
Status = "sent",
CompositeTemplates = new List
{
compositeTemplate1,
compositeTemplate2
},
};
When the Sign on Paper workflow is used, the document that the recipient signs is added to the envelope as an attachment. Because of this, it’s important to consider how your application should handle signed documents.
The simplest way is to request the combined document, which will result in a single PDF with the wet-signed copy appended to the end. If the PDFs need to remain separate, an EnvelopeDocuments::List call can be used to check for the presence of wet-signed files. DocuSign Connect can also be used: even with the option to Include Document PDFs disabled, the Connect packet will include filenames and IDs of all envelope documents.
In either case, wet-signed copies can be identified by the filename, which begins with “Signed-on-Paper_” and includes a randomly generated GUID. Note that there’s nothing in the Recipients definition that defines whether a user signed electronically or on paper. There’s also no validation of whether the signer actually completed their role correctly. If there’s no room for ambiguity in your workflow, it may be best to explicitly disable wet signing, or at least add an additional role to validate the provided input.
While Sign on Paper solves the problem of needing to accommodate a physical signing in a workflow, it presents a number of issues that should be considered before implementation:
- It’s not immediately clear through the eSignature API or DocuSign Connect when Sign on Paper (wet signing) is used.
- DocuSign is unable to collect form data from recipients using wet signing.
- DocuSign is unable to validate that the signer-provided document is filled out correctly, or even that the document returned is the correct document at all.
- If the customer selects the Fax-Back option instead of Scan-and-Upload, processing could be further delayed.
- The wet-signed copy will be a separate document in the envelope.
- There’s no simple way to merge envelope documents that have been wet-signed by multiple recipients. A combined PDF is available, but will contain duplicate pages with individual signatures.
|
|
Thanks to Drew Martin on our developer support team for providing this tip on integrating wet-signing documents into your esignature workflows.
|
|
|
Top Trending Topics
The top trending topics on Stack Overflow for the docusignapi tag are determined based on views and/or comments on specific threads. Here are the top three most frequently asked or viewed questions and answers:
Thread: API returning a USER_LACKS_MEMBERSHIP error
Summary: The developer had an integration using JWT that they were taking from the Developer Sandbox (demo) into production ( Go Live Process). The developer was only getting the error USER_LACKS_MEMBERSHIP in production while everything was working fine in demo.
Answer: The Developer Sandbox only has a single endpoint for API calls: demo.docusign.net. In production we have multiple endpoints for different locales. Making calls to www.docusign.net may result in this error. To discover the correct baseUrl for your account, you need to call the getUserInfo() method of the eSignature REST API.
Thread: DocuSign Connect Webhook with .NET Core 3
Summary: The developer is building an app using Microsoft .NET Core version 3 that attempts to receive notifications from DocuSign using the DocuSign Connect Webook. The developer was checking their Connect logs and found they consistently get “The remote server returned an error: (415) Unsupported Media Type.”
Answer: The media type for Connect calls is XML. The developer had to add AddXmlSerializerFormatters() to the ConfigureServices method in Startup.cs instead of services.AddMVC().AddXmlSerializerFormatters() as well as added the [FromForm] attribute to resolve this issue.
Thread: How to fix curl error “Could not resolve host: account-d.docusign.com%2Foauth%2Ftoken” in Docusign API in php
Summary: The developer is building an application using the PHP language and making Curl calls to the API (not using the SDK) and is getting the error about a bad URL as part of the Auth Code Grant authentication flow.
Answer: The URL in question has an encoding issue, as it should be the encoded URL https://account-d.docusign.com/oauth/token; but the code somehow has some of the slashes encoded. The slash character can be encoded within a URL parameter (after the “?” mark) that is passed to an endpoint, but not within the actual URL path itself.
If you’d like to contribute to the community or ask a question, please visit us on Stack Overflow. Don’t forget to visit our Developer Center for complete documentation on how to use the DocuSign eSignature API.
|
|
Upcoming Events
Dreamforce 2019—November 19-22, 2019
Dreamforce 2019 is coming, and DocuSign will be there! Our Developer Evangelism team will be on hand to demonstrate our Apex Toolkit for building DocuSign integrations for Salesforce. You can meet the team, get tips, take hands-on courses, and collect swag!
DeveloperWeek Austin—November 6 and 7, 2019
DeveloperWeek Austin 2019 is the largest developer event in Texas, with 2,000+ application developers, engineers, development managers, and executives coming together for two days of learning and networking. Register to come and meet the team, hear our presentation by Developer Evangelist Lauren Dunne, and checkout DocuSign Developer Labs, our interactive DocuSign developer tutorial.
Devoxx Belgium—November 4-8, 2019
Devoxx Belgium is a five-day conference where Java developers and architects come together and explore the latest technology advancements and fascinating ideas. If you’re on your way, come and meet our engineering team, solve puzzles, and win swag at the largest gathering of Java developers in Europe.
API Office Hours: Live Q&A with our API Experts—November 12, 2019, 9 a.m. PST
Join us for live Q&A sessions with our API experts, where you will learn how you can leverage our developer platform and begin integrating with the DocuSign APIs (or with one of our popular SDKs). We’ll start with a quick “Hello World” demo to show you how easy it is to get started with integrating DocuSign eSignatures into your app or website. Next, we’ll open it up for Q&A and have our API and SDK experts on-hand to answer all of your technical questions, including (but not limited to): authentication, go-live process, best practices, developer resources, and more. Register to attend the free session.
|
|
Share Your Feedback
We want to make sure that this newsletter is as useful as possible. Here is a link to a very short survey – please take a minute to give us feedback.
|
|
|
|
|