HelloSign to Dropbox.SignWelcome! Dropbox Sign's new Dotnet SDK is generated from our officially maintained OpenAPI spec. In this release, we've made important updates that introduce new functionality and create feature parity between the Dropbox Sign API and the Dotnet SDK. However, some of these changes are considered "breaking" in the sense that they'll require you to update your existing code in order to continue using the SDK.
In this migration guide, we'll cover core concepts in the new SDK, highlight differences from legacy versions, and provide example code showing how past implementations map to the new version's syntax. We'll link out to supporting documents that offer more context behind the breaking changes and why we made them. We apologize for any inconvenience these changes may cause, but are confident the new features will add value to your integration.
Remember that we are here to help if you have any questions or need assistance along the way. Thank you for using Dropbox Sign's Dotnet SDK. We hope you enjoy the improvements!
As mentioned above, the new Dotnet SDK (Dropbox.Sign) is generated from our OpenAPI Spec. Some of the architectural changes impact the tools and locations you use to interact with the SDK.
This section contains the core concepts and patterns of the new SDK and highlights differences from the legacy SDK.
There are two methods for installing the new OpenAPI Dotnet SDK:
dotnet add package Dropbox.Sign —version 1.0.0git clone https://github.com/hellosign/dropbox-sign-dotnet.gitdropbox-sign-dotnetRun: dotnet pack
src/Dropbox.Sign/bin/Debug/Dropbox.Sign.1.0.0-*.nupkgNuGet.Config file at the root level of the existing projectAdd the following code to your NuGet.Config file:
Reference the package within the .csproj file:
dotnet runThe New Dotnet SDK organizes methods and classes across multiple namespaces; each with a specific purpose.
To set-up your configuration and set the HTTP basic authenticator:
Client class with your API key.Client class and pass OAuth Access Token in the .UseOAuth2Authentication() method.Configuration class and set your API Key as the Username.Configuration class and set bearer authorization: oauth 2 token as the AccessToken.The new SDK divides endpoints across unique Classes:
Models are used to define the structure and value of the parameters being passed. The fully assembled model is passed to the API endpoint method.
New SDK Using Models to Pass Parameters
In the legacy SDK you would pass Path and Query parameters alongside any POST data to the API endpoint:
Legacy SDK - Path and Query Parameters
The new SDK now requires POST data be an object when calling any API endpoint. Path and Query parameters must be passed individually to these methods.
New SDK - Path and Query Parameters
The New SDK handles errors and warnings differently. See the table below for a breakdown of the changes:
Errors are an instance of Dropbox.Sign.Client.ApiException with its ErrorContent getter returning an instance of Dropbox.Sign.Model.ErrorResponse class and should be handled using Try/Catch blocks.
Warnings are a list of Dropbox.Sign.Model.WarningResponse.
There are three ways to instantiate an object.
Init() static methodInit() creates a full object using all the data you pass, including nested data to instantiate nested objects. Any parameters that you do not pass data for will be set to their default value (including null).
A callback helper class is included in the New SDK repo to assist in verifying callbacks. The helper simplifies:
The EventCallbackHelper and EventCallbackRequest classes facilitate parsing of event data and assist in validating that a callback originated from Dropbox Sign.
We will send event callback payloads to you as a multipart/form-data request with a single json formfield that contains your event callback as a JSON string.
Example Event Callback Request From US to YOU
Example JSON Payload
How to use the EventCallbackHelper
This section highlights larger changes to be aware of when migrating to the new SDK.
The Form Fields per Document parameter has changed from a two dimensional array, to a one dimensional array—allowing you to designate which file you to add the field to using document_index. You can learn more about this change here: Form Fields per Document.
There are several different types of form fields you can define, identified by the value of the type field and a few ways to instantiate the correct object when making an API request.
The different classes for each type are:
You can use ::init() on the base request class
You can use ::init() on the field class
You can instantiate the class directly
Form Fields per Document Examples using the new SDK:
signers ObjectIn the Legacy SDK when making a Signature Request using a Template the signers property was an object with the role name as the key. In the new SDK the role value has been moved into the signer object itself.
For example for the /signature_request/send_with_template endpoint the signers property could be represented as:
Using the new SDK you would now send this data as follows:
ccs PropertyIn the Legacy SDK when making a Signature Request using a Template the ccs property was an object with the role name as the key. In the new SDK the role value has been moved into the cc object itself, alongside a new email_address property.
For example for the /signature_request/send_with_template endpoint the ccs property could be represented as:
Using the new SDK you would now send this data as follows:
custom_fields PropertyIn the Legacy SDK when making a Signature Request with the custom_fields property it was an object with the name as the key. In the new SDK the name value has been moved into the custom_field object itself.
For example for the /signature_request/send_with_template endpoint the custom_fields property could be represented as:
Using the new SDK you would now send this data as follows:
template_id to template_idsThe template_id parameter has been removed. You must now use template_ids.
file to filesThe file parameter has been renamed to files. Usage remains the same.
Use .Files([...]);
file_url to file_urlsThe file_url parameter has been renamed to file_urls. Usage remains the same.
Use .FileUrls([...]);
The new SDK version introduces some new patterns around uploading and downloading files. You can read about them more in depth here: Interacting with Files.
The file upload process changed with the newly-adopted OpenAPI-specification — it is no longer possible to pass file paths into file upload methods. You can learn more about this update here: New Patterns: Interacting with Files.
The New Dotnet SDK only accepts files passed as binary. For more information, see Interacting with Files.
Please see the comments in the New Dotnet SDK code sample below for detailed description of passing the file as binary.
The New Dotnet SDK downloads files differently. You can learn more about why this change was made here: Interacting with Files.
Switch between file format using parameters sent to a single endpoint for either downloading files or downloading templates.
Switch between file formats by calling an endpoint specific to that format. You can see how those are split up in the table below.
Downloading Templates
Get a head start migrating or planning your migration using the code examples in this section. We created examples for our most-used endpoints. Reach out if you think we’re missing an important one.
Following the official release of the new SDK version, we'll be preparing to deprecate all legacy versions of the Dotnet SDK for one year after launch. That means, once fully launched, we'll only support critical vulnerabilities and bug fixes for legacy SDK versions 1.5.3 for 12 months. After that, legacy versions are considered officially deprecated and are no longer supported. You can find more information in our SDK Versioning Policy.
We encourage you to start migrating (or planning to migrate) to the new SDK as soon as possible. Please don't hesitate to reach out if you have questions or need assistance.
We know that dealing with "breaking" changes is inconvenient for those of you currently using the legacy SDK, but believe the new SDK offers a better experience while providing access to more features. If you need help or get stuck, please reach out to API support: Submit a Ticket
We warmly welcome your feedback, feature requests, and bug reports in our OpenAPI repo. All of the engineering work on the Dotnet SDK happens in the Dotnet folder of the repo.