C# eSignature SDK v6 supports custom HTTP clients

The Developer Engineering team here at Docusign are very excited to announce our C# eSignature SDK v6, the latest major release of our open-source eSignature SDK, which provides easy integration with Docusign eSignature APIs! Over the years, we have worked very hard to provide developers with a smooth and frictionless experience partnering with Docusign using our SDKs, and we are proud that our team continues to innovate and keep a developer-first mentality while pursuing these goals.  The team’s hard work has culminated in several big advantages for developers upgrading to the latest release, including the removal of a third-party dependency (which should help to avoid versioning conflicts among dependencies and provide one less vector for a vulnerability) as well as support for custom HTTP clients for when a custom setup is necessary or preferred by the developer.

Why did we decide to make this change?

First, we have heard from developers in the past that they were running into version conflicts when integrating with the C# SDK due to our dependency on the RestSharp NuGet package. This version conflict manifests itself in a few different ways, including a developer updating other project dependencies that also rely on RestSharp or developers updating RestSharp within their own project to a conflicting version. No matter how it happens, the team here at Docusign wanted it to stop. As developers ourselves, we’re all too familiar with dependency conflicts (sometimes termed “DLL hell”), so we’re pleased that we can take that pain away from developers using our SDKs.

In addition, we wanted to remove unnecessary potential vulnerabilities. The more dependencies there are in a project, the more potential there is for one of those dependencies to be exploited in some way. To that end, we wanted to reduce the number of dependencies that our SDK has in order to limit the exposure developers would have when they integrate with the Docusign eSignature C# SDK.

Lastly, and probably most important, we wanted to provide developers with simplicity of integration when the default HTTP client configuration is all that’s necessary, but also an option for HTTP client customization for cases where a more complex client is necessary. In our new SDK, by default we provide an HTTP client based on System.Net.Http.HttpClient, which should fit most customers’ needs. In addition to that option, developers can provide a custom HTTP client to meet their very specific needs (for proxy configuration or custom timeouts, for instance).  Before, customers were limited to the configuration options provided by RestSharp, but now customers can provide a fully customized HTTP client that meets their needs.

How can developers leverage this new feature?

Customers upgrading from our C# SDK v5 should only be required to make minimal changes (sometimes, simply replacing ApiClient with DocuSignClient is all that’s necessary) since the DocuSignClient class was built while considering backward-compatibility with ApiClient.

Here is a basic example of using the new built-in HTTP client for getting a single envelope:

DocuSignClient client = new DocuSignClient("https://demo.docusign.net/restapi");
byte[] privateKeyBytes = Convert.FromBase64String(PRIVATE_KEY_STRING);

OAuth.OAuthToken tokenInfo = client.RequestJWTUserToken(
INTEGRATOR_KEY,
USER_ID,
OAUTH_BASE_PATH,
privateKeyBytes,
EXPIRES_IN_HOURS,
SCOPES_LIST);

EnvelopesApi envelopesApi = new EnvelopesApi(client);
Envelope env = envelopesApi.GetEnvelope(ACCOUNT_ID, ENVELOPE_ID);

Pretty simple, right? In just a handful of lines of code, our SDK provides developers with a quick and easy method for integrating with Docusign eSignature APIs; it almost could not be easier!

What about developers with specific requirements?

Customers with specific requirements, limitations, and business needs can implement a custom HTTP client that meets their own specifications. To use a custom HTTP client, all that the developer needs to do is to implement the Docusign.eSign.Client.IHttpClient interface, which only includes three methods, and then provide that custom class to the DocuSignClient class via its constructor.

An example of how a custom HTTP client might be implemented is contained within the SDK in a class called Docusign.eSign.Client.SystemNetHttpClient. This default HTTP client is built on top of the .NET runtime’s System.Net.Http.HttpClient class and is used by DocuSignClient if no other HTTP client is provided during instantiation. Our team implemented this default HTTP client in a similar manner to how a customer might implement their own HTTP client should a customer need or want to do so.

Once a custom HTTP client has been created, it’s a simple change to integrate that into the sample code above. As an illustration, all you need to do to the sample code above to use the SystemNetHttpClient class built into the SDK is to change the following line:

DocuSignClient client = new DocuSignClient("https://demo.docusign.net/restapi");

to this:

SystemNetHttpClient customClient = new SystemNetHttpClient();
DocuSignClient client = new DocuSignClient("https://demo.docusign.net/restapi", customClient);

Legacy ApiClient deprecation

The Docusign team has marked the legacy Docusign.eSign.Client.ApiClient class as obsolete with the intention of ultimately removing it. For now, it has been left in for backward compatibility, but warnings (or errors depending on build settings) will be triggered at build time if the legacy ApiClient class is used while v6 of the SDK is being referenced. Any code using ApiClient should simply change to use the new DocuSignClient instead. Everything else should remain the same and work just as it did before.

Implementation across our APIs

Docusign produces SDKs for several of our REST APIs, including Rooms, Monitor, Admin, and Click. Corresponding updates to these SDKs are in process. Look for the remainder of our C# SDKs to receive this same update soon.

Parting thoughts

I’d also like to thank my fellow Docusign engineers on the Developer Experience Team, and Bharat Rele in particular, for their continued support and contributions to this major update.

That’s all for now. We will be continuing to make strides to improve our SDKs and make the integration experience as pleasant and easy as possible. We would love to hear from you, so send any suggestions to developers@docusign.com; and don’t forget to subscribe to the Docusign Developer Newsletter to keep informed of all our latest news and releases.

Additional resources

• Docusign Developer Center

• @DocuSignAPI on Twitter

• Docusign for Developers on LinkedIn

• Docusign for Developers on YouTube

• DocuSignAPI on Twitch

• Docusign Developer Newsletter