The changes between REST API v5 and v6 require bigger changes of the API client implementations, as this version switch addressed many known disadvantages of the v3-v5 API versions. This migration guide should give an overview on how to migrate from API v5 to API v6. As there are no big changes between v4 and v5, this guide will also be helpful for integrations that are still on API v4. For those for projects that are still using API v3 or v4, we recommend to migrate to v5 first following the v3 to v5 guide, and then migrate in a 2nd step from v5 to v6 using this guide.
...
Info | ||
---|---|---|
| ||
Please keep using API v5 if you are using one of this features listed below:
|
...
We take into account that the words "whitelist" and "blacklist" can be perceived as offensive and hurtful words. It has never been our intention to imply discriminatory or other-valued meanings in the use of these terminologies beyond the purely technical interpretation of including or excluding a subset of parameters from larger sets. We have changed our terminology to "allowlist" and "blocklist" to reflect the worldwide discussion of these terms over the past two years, or are now using descriptive namings for an inclusion lists such as in the ActionCallbackSelection.
In an eSignAnyWhere Envelope, we are now using the term "activity" instead of "recipient". The term "recipient" didn't work gracefully for situations where the "recipient" was just a background service activity such as an "automatic signing" or "automatic sealing" activity. We follow the terminology borrowed from the Business Process Modelling Notation (BPMN), as we consider an envelope as being processed in a signature workflow.
...
API v1-v5 | API v6 | |||
---|---|---|---|---|
Status Values envelope/get | Status Value envelope/find | Status Value envelope/get | Status Value envelope/find | Comment |
Started | Active | Active | Active | |
InProgress | ||||
ActionRequired | ActionRequired | ActionRequired is a status interpretation (derived from "Active") in context of the current user who calls envelope/find. | ||
WaitingForOthers | WaitingForOthers | WaitingForOthers is a status interpretation (derived from "Active") in context of the current user who calls envelope/find. | ||
Completed | Completed | Completed | Completed | |
CompletedWithWarnings | ||||
Canceled | Canceled | Canceled | Canceled | |
Rejected | Rejected | Rejected | Rejected | |
(ExpiringSoon) | ExpiringSoon | Active | ExpiringSoon | ExpiringSoon was defined in the v5 model of envelope/get, but actually not used. |
Expired | Expired | Expired | Expired | |
BulkCompleted | (n/a) | (n/a) | (n/a) | Separated to API methods in "/envelopebulk" route |
BulkPartlyCompleted | (n/a) | (n/a) | (n/a) | Separated to API methods in "/envelopebulk" route |
Draft | Draft | (n/a) | (n/a) | Separated to API methods in "/draft" route |
Template | Template | (n/a) | (n/a) | Separated to API methods in "/template" route |
...
The functionality of both methods
POST /v5/envelope/:envelopeId/restart
- GET /v5/envelope/:envelopeId/restart/{expirationInDays} (where the verb GET was misleading)
...
The method GET /v5/envelope/{templateId}/copyFromTemplate was replaced by 2 methods: First of all use POST /v6/template/createdraft to create a new draft based on the template, and in a 2nd step use POST /v6/draft/send to make the draft an envelope.
User Management
Just a small renaming applied for /v5/userById/{userId}. Its new name is GET /v6/user/{userId}.
The functionality of GET /v5/userByEmail/{email} (which is similar to the old but deprecated GET /v5/user/{email} ) is now covered by the POST /v6/user/find method.
System
To check the eSignAnyWhere version, also often used to perform a system availability check, the method GET /v4/version was moved into a group of "system" related methods and therefore changed to GET /v6/system/version
...