Node Migration Guide
Migrating the Node SDK from hellosign-sdk to @dropbox/sign
Welcome! Dropbox Sign's new Node 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 Node 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 Node SDK. We hope you enjoy the improvements!
Architecture and Tooling
As mentioned above, the new Node 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.
SDK Resources
- Download -- using this new npm repo. New Node SDK versions will now be published here.
- Development -- active development against the Node SDK happens here: hellosign-openapi/sdks/node.
- SDK GitHub Repo -- dropbox-sign-node is updated based on changes to hellosign-openapi/sdks/node, but no active development work happens there.
- Reference Docs -- the automatically generated Reference Docs are a great way to explore the SDK.
- Examples -- our full suite of ready to use examples will help you get started quickly.
- Engagement -- use the OpenAPI repo to submit Issues or Pull Requests for the Node SDK.
Core Concepts and Patterns
This section contains the core concepts and patterns of the new SDK and highlights differences from the legacy SDK.
Installation
There are two methods for installing the new SDK:
Install from NPM
Optionally, to scaffold your
package.jsonfirst run:To install from NPM run:
Build from Source
Clone the repo locally
- Run
npm pack Move generated file (
dropbox-sign-1.0.0.tgzor similar) to your project directoryIn the
dependenciesarray of yourpackage.jsonfile, addRun
npm install
Importing the SDK
The new Node SDK is packaged as an ES Module rather than CommonJS, which means you’ll bring it into your code base differently.
Legacy Node SDK
Use require statement to bring in the entire Dropbox Sign SDK.
New Node SDK
Use import statement to add the entire SDK or only the pieces you need.
To support ES Modules and use import statements in your Node project, your package.json file must contain "type": "module".
Authentication
Rather than one big SDK with access to everything, the new Node SDK is organized into groups of similar endpoints.
Legacy Node SDK
Pass credentials once when instantiating the SDK.
New Node SDK
Pass credentials each time a new section of the SDK is instantiated (Signature Request, Template, Account, etc.)
Endpoints Grouped into Classes
The new SDK divides endpoints across unique Classes:
Using Models to Pass Parameters
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
Path and Query Parameters
When passing parameters to the API methods in the legacy SDK it was standard to pass the parameters inside of an object to the API method. For example using the opts object below:
Legacy SDK - Path and Query Parameters
The new SDK no longer accepts objects when passing path or query parameters to endpoints. Instead you will need to pass the parameters as separate variables such as accountId and page below:
New SDK - Path and Query Parameters
Endpoints that have both path or query parameters, and accept POST data, will have a mix of both styles:
Error Handling and Warnings
The New SDK handles errors and warnings differently.
Error Handling
Errors are an instance of HttpError with its body parameter being an instance of ErrorResponse class and should be handled using Try/Catch blocks.
Warnings
Warnings are a list of WarningResponse.
New SDK - Warnings
Instantiating Objects From Data
There are two ways to instantiate an object.
- You can instantiate a class directly and use setters to set your data
- You can use an object literal that matches expected type definitions
Event Callback Helper
A callback helper class is included in the New SDK repo to assist in verifying callbacks. The helper simplifies:
- Checking event authenticity with built in event hash check
- Displaying event types (account callback vs. app callback)
- Displaying event messages
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
Native TypeScript Support
The new SDK is written in TypeScript and comes fully typed for the best possible developer experience.
If you do not use TypeScript you can still use the new SDK as normal.
Differences from Legacy SDK
This section highlights larger changes to be aware of when migrating to the new SDK.
Form Fields Per Document
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 documentIndex. You can learn more about this change here: Form Fields per Document.
Instantiating the Correct Field Class
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 a literal object definition with no typing:
You can also instantiate an instance of the correct class. In this scenario the type field is automatically set to the correct value for you:
If you are using TypeScript you can use a literal object definition with typehint on the object itself. If you use a typehint any invalid or missing data will be highlighted on the object itself in your IDE.
If you use TypeScript but do not typehint the object, you will see the error when passing the data to the API endpoint.
”role” Value in signers Object
In 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:
“role” Value in ccs Property
In 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:
“name” Value in custom_fields Property
In 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_ids
The template_id parameter has been removed. You must now use template_ids.
file to files
The file parameter has been renamed to files. Usage remains the same.
file_url to file_urls
The file_url parameter has been renamed to file_urls. Usage remains the same.
snake_case to camelCase
The variables, properties, and functions in the Legacy SDK were written in snake_case. The New SDK now uses camelCase instead, as this is what is standard practice for Node.
Interacting with Files
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.
Uploading Files
Passing a file with with your API request using the files parameter is different:
Downloading Files
Download functionality is now spread across multiple endpoints.
Downloading Templates
Endpoint Mapping
This section shows you how endpoints in the legacy SDK map to the new SDK. It doesn’t cover all endpoints, but gives you an idea of mapping implementations between the two SDKs. Please reach out if you think we’re missing an important example.
- Get Account
- Get Signature Request
- Send Signature Request
- Create Embedded with Template
- Update API App
Get Account
Get Signature Request
Send Signature Request
Create Embedded with Template
Update API App
Supporting Legacy SDKs
Following the official release of the new SDK version, we'll be preparing to deprecate all legacy versions of the Node SDK for one year after launch. That means, once fully launched, we'll only support critical vulnerabilities and bug fixes for legacy SDK versions 2.1.0 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.
Feedback and 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 Node SDK happens in the Node folder of the repo.