Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

API v5 will remain part of the product beyond the announced removal of v3, while REST API v6 is already available. For existing integrations, staying on API v5 is ok as long as no new features of v6 are required, but our recommendation is to start early to migrate to API v6 even in consideration of the effort, to be prepared for the situation when you need a new functionality that is available on API v6 only.

For new customers, and also for new projects at existing customers, we strongly recommend to start with REST API v6.


Warning

Important information: If you have been utilizing the API v5 to create envelopes and are planning to retrieve theses envelopes using API calls from v6, it is crucial to be aware of potential compatibility issues.

Due to changes and updates between API versions, certain calls made from v6 may result in errors related to invalid API version ("InvalidEnvelopeApiVersion") when attempting to retrieve envelopes created with API v5. A possible solution is to continue using the v5 calls to retrieve the envelopes created via v5 if one of the following API calls is needed to retrieve the envelope/template or draft. See following affected api call:

  • Draft/GetElements
  • Envelope/Get
  • Envelope/GetConfiguration
  • Envelope/GetElements
  • Template/GetElements


Info
titleCurrently Non-Supported Functionality

Please keep using API v5 if you are using one of this features listed below:

  • The mode SequenceOnlyRequiredTasks was removed from APIv6. A sender can still decide between NoSequenceEnforced and SequenceEnforced, and based on our experience SequenceEnforced can be used for those scenarios where SequenceOnlyRequiredTasks was used in some cases. We did this change to reduce complexity for integrators, and may decide in a future release if SequenceOnlyRequiredTasks needs to be added again.
  • Support for Swisscom Automatic Signatures / Swisscom Organization Certificates will be added in a later release.
  • Support for document links to bookmarks (i.e. within one document, or from one document to another). Only hyperlink areas to WWW resources are supported.
  • Some functionality formerly possible to be set via eSAW API in undocumented data structures, e.g. parameters just interpreted in SIGNificant app, Kiosk etc but not available in SAW Viewer, are not contained in APIv6 models. Please check for such functionality, in case you used it before, already before starting to migrate to APIv6. This functionality will be added to APIv6 in a later product version, if it is considered as important product functionality. In case such functionality will be added to APIv6, then it will be available also in eSAW envelope creator and SAW Viewer.
  • User Management - there is currently no /user/* endpoint in API v6. For user management, keep using API v5, until we add new user management methods to API v6 in a future product version
  • OverrideHolderInCaseOfMismatch  was removed from APIv6
  • ViewerPreferences were removed from APIv6. Only configurable in the customization.zip: SignAnyWhere Viewer - Customization#ViewerPreferences 
  • SignatureRenderingLayout was removed from APIv6. It is therefore not possible to add the layout to the signature field.
  • Signing certification via thumbprint was removed from APIv6. But please note that it is possible to add
Info
titleCurrently Non-Supported Functionality

Please keep using API v5 if you are using one of this features listed below:

  • The mode SequenceOnlyRequiredTasks was removed from APIv6. A sender can still decide between NoSequenceEnforced and SequenceEnforced, and based on our experience SequenceEnforced can be used for those scenarios where SequenceOnlyRequiredTasks was used in some cases. We did this change to reduce complexity for integrators, and may decide in a future release if SequenceOnlyRequiredTasks needs to be added again.
  • Support for Swisscom Automatic Signatures / Swisscom Organization Certificates will be added in a later release.
  • Support for document links to bookmarks (i.e. within one document, or from one document to another). Only hyperlink areas to WWW resources are supported.
  • Some functionality formerly possible to be set via eSAW API in undocumented data structures, e.g. parameters just interpreted in SIGNificant app, Kiosk etc but not available in SAW Viewer, are not contained in APIv6 models. Please check for such functionality, in case you used it before, already before starting to migrate to APIv6. This functionality will be added to APIv6 in a later product version, if it is considered as important product functionality. In case such functionality will be added to APIv6, then it will be available also in eSAW envelope creator and SAW Viewer.
  • User Management - there is currently no /user/* endpoint in API v6. For user management, keep using API v5, until we add new user management methods to API v6 in a future product version
  • OverrideHolderInCaseOfMismatch  was removed from APIv6
  • ViewerPreferences were removed from APIv6. Only configurable in the customization.zip: SignAnyWhere Viewer - Customization#ViewerPreferences 
  • SignatureRenderingLayout was removed from APIv6. It is therefore not possible to add the layout to the signature field.
  • Signing certification via thumbprint was removed from APIv6. But please note that it is possible to add a custom sealing certificate via UI as well as via API - Custom Sealing Certificate
  • The parameter "AttachSignedDocumentsToEnvelopeLog" was removed from APIv6 and therefore it is not possible to add signed documents to audit trail.

Already implemented:

See also eSignAnyWhere Release News for more detail.

  • GeneralPolicies were added to the UI as well as for the API v6 with version 23.49
  • Support for modifying SMS-OTP message (language and content) was added with version 23.49

...

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. 

To emphasize the global aspect of the solution, we have adapted terminologies so that they are suitable for worldwide use. One example is the division of the name into the firstName and lastName, which is not common in every region of the world. Based on common recommendations, we are now using the terms givenName and surname.

Envelope Status Enumeration

The envelope status values have been reviewed, and status values are now aligned with the status value shown in the WebUI.

...

Business Process Modelling Notation (BPMN), as we consider an envelope as being processed in a signature workflow. 

To emphasize the global aspect of the solution, we have adapted terminologies so that they are suitable for worldwide use. One example is the division of the name into the firstName and lastName, which is not common in every region of the world. Based on common recommendations, we are now using the terms givenName and surname.

Envelope Status Enumeration

The envelope status values have been reviewed, and status values are now aligned with the status value shown in the WebUI.

API v1-v5API v6
 Status Values
envelope/get
Status Value
envelope/find
Status Value
envelope/get
Status Value
envelope/find
Comment
StartedActiveActive

Active
InProgress


ActionRequiredActionRequiredActionRequired is a status interpretation (derived from "Active") in context of the current user who calls envelope/find.
WaitingForOthersWaitingForOthersWaitingForOthers is a status interpretation (derived from "Active") in context of the current user who calls envelope/find.
CompletedCompletedCompletedCompleted
CompletedWithWarnings
CanceledCanceledCanceledCanceled
RejectedRejectedRejectedRejected
(ExpiringSoon)ExpiringSoonActiveExpiringSoonExpiringSoon was defined in the v5 model of envelope/get, but actually not used.
ExpiredExpiredExpiredExpired
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
DraftDraft(n/a)(n/a)Separated to API methods in "/draft" route
TemplateTemplate(n/a)(n/a)Separated to API methods in "/template" route

Disposable Certificate Enumeration

Please see the following changes referring to the identification types and the document types for disposable certificate:

Identification type

API v5API v6
NoneNone
FOREIGN_TAX_CODEForeignTaxCode
PERSONAL_NUMBER

PersonalNumber

PASSPORTPassport
NATIONAL_IDENTITY_CARDNationalIdentityCard
ITALIAN_TAX_CODEItalianTaxCode
NO_SERIAL_NUMBERNoSerialNumber
DRIVING_LICENSEDrivingLicense
RESIDENCE_PERMITResidencePermit
RESIDENCE_PERMIT_TEMPTemporaryResidencePermit
EMBASSY_DOCUMENTEmbassyDocument

Document type

API v5API v6
CIIdentityCard
PADriverLicense
PASS

Passport

RPResidencePermit
CIENationalElectronicIdentityCard
RTTemporaryResidencePermit
DCEmbassyDocument
PD*
ID*
PN*
AT*

*Not supported with api v6 and UI - but still available with older api versions than api v6.

...

Complexity Reduction

Structural Changes for Bulk Sending via API & for managing parent envelopes resulting from bulk-sending

...