Page tree
Skip to end of metadata
Go to start of metadata

This page shows the features with the respective versions. For detailed information about LTS (Long-Term-Support) please have a look at: eSignAnyWhere Release Policy
Current LTS version: 21.76

Explanation of Feature Release and LTS Release:

Feature Release: New functionality, lower priority fixes

Long-Term-Support-Release (LTS): 2 years of guaranteed hotfixes for critical bugs and Critical/High security findings.

Feature Release

eSignAnyWhere 22.50

Date: Planned February 2023 (Release Candidate installed on Demo already)

Beside, focusing on stabilizing and improving existing features to make them even better to use, following new features are available with this version:

Api v6

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.

Please note: The guides listed below refer to the new api version 6. If documentation for versions below v6 are needed please have a look at: Outdated documentation

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. For information about conceptual changes and changes on method level please see the Migrate REST API clients from v5 to v6.

Addressing some conceptual changes also here:

  • All naming in the API, on method level and inside the models, have been reviewed (and most of them have been changed) because we think consistent and simple wording helps to speed up the learning curve of the API users

  • We removed historic relics that come from technical architecture (e.g. „workstepConfiguration“) because API users shouldn't burn time by understanding internal concepts of our platform
  • We are using only the verbs GET and POST; and strictly avoid using PUT, PATCH, DELETE and other HTTP verbs again for simplicity, but also to avoid issues with some coding platforms and infrastructure configurations where customers reported issues in the past.

Additionally, with the  Tutorial: Hello World and the REST tutorial using Postman you get to know the basic concepts of the api. Please also see the Integration guide which contains different use cases as well as guides for starters: Integration Guide

UI extensions

For detailed information about the changes on existing form fields as well as information about new fields please have a look at: Designer Page

With this setting it is possible to define a specific order for the tasks. In addition to order the tasks by drag and drop it is also possible to define a sequence mode:

  • No sequence enforced - allow form filling in any order
  • Sequence required tasks
  • Sequence enforced - enforce sequence for all tasks

With the link form field it is possible to add hyperlinks to the document. This allows the recipient to just click on the link to navigate to linked pages.

Read confirmation (if one of the following is selected as required the recipient then must confirm that he/she has read the area, page or the document. You can choose between the following:

  • Read confirmation (Area)
  • Read confirmation (Page)
  • Read confirmation (Document)

It is now possible to add a validation for the textbox. You can choose between the following validations:

  • None
  • Date
    • Format
    • Minimum value
    • Maximum value
  • Email
  • Number
    • Decimal Places
    • Symbol
    • Symbol location
    • Group Separator
    • Decimal Separator
    • Minimum value
    • Maximum value
  • Phone
    • Phone type
      • international
      • international leading zeros
      • international leading plus
  • Time
    • Format
    • Minimum value
    • Maximum value

By enabling the "Custom Signature Image" checkbox, the sender can allow (or enforce) that the signer is uploading an additional image to be shown in the signature field. Such custom signature images can be used to ask for placing a company stamp picture, or to insert Hanko stamps. See Story: Using external signature images for additional use case details. Note that the global setting here sets and overrules the signature-type specific settings, as this property can also be defined on a per-signature-type level in the Advanced tab.

Additionally to the general settings you can define the following in the advanced settings for attachment fields:

  • Attachment icon
  • Either enable or disable to set a custom file name and if enabled enter a file name

Additionally to font size and text color you can also choose between italic and bold. This option is available for the following fields:

The same settings (elementId and FieldDefinition) can also be set for the following predefined fields:

  • EmailFields
  • InitialsFields
  • GivenNameFields
  • SurnameFields
  • FullNameFields
  • DateFields
  • Static Text

The middle name can now be added for the initials.

Additionally to the text field it is also possible to add a predefined static text to the document.

Please note the following: It is possible to add a static text although the document was already signed. This is the main difference between the textfield and the static text as a predefined element.

A "Render as Checkbox" option, which allows to change the visual appearance of a radio button () to the visual appearance of a checkbox (). The appearance is affecting both the representation in the designer page's main editor, and of course the signer's view in SignAnyWhere Viewer. The behavior is still the behavior defined for a radio button, i.e. only one of the radio button group can be selected. The setting will not be considered when opening the workstep in Kiosk SDK or the SIGNificant Client Signature Capture App.


Please note that the organization api token can only be used with REST api version 1 to 5.

Beside the language, email settings and the personal message you can now also add the following:

  • Language
  • Email settings
  • Personal message
  • Activity settings

You can now find the recipient finish actions on the create envelope page in the recipients section:

You can now find the recipient finish actions on the create envelope page in the recipients section:

Signature fields

General information

Please note the following:

The "Advanced Settings" tab allows to set additional parameters.

At the top of the advanced settings, the sender can change the appearance of the signature rendering:

  • Define the date format used for rendering the date on a signature field
    (this configuration will be ignored when defining a specific date format in a custom stamp imprint configuration that is applied organization wide for all or some signature types)

As many settings are different per signature type, the advanced settings tab also lists all signature types which have been allowed on the General tab. For each of the signature types, a settings section (which is by default collapsed) can be expanded. Some of these settings can be defined per signature type, but same options are available for all signature types to allow independent configuration.

UI signature validity in second. This setting is used by the following signature types:

  • DisposableCertificate
  • SwissComOnDemand
  • RemoteCertificate
  • OneTimePassword

Disposable certificate advanced settings now also contains the option to select a long lived certificate. You can also force this setting in the organization settings.

On a signature field which allows recording a biometric signature, the biometric verification can be enabled in case the (optional) SIGNificant Biometric Server was also installed and properly configured.

When enabling the biometric verification, the sender has to provide the signer's user ID which was used to enroll a profile.

The sender can configure behavior of the biometric verification:

  • It is possible to allow to skip the verification (in case the matching score is below the required threshold).
  • The signature field can be configured to allow enrolling signatures to a profile if there have not been enough signatures enrolled to the profile yet.

Another option allows the sender to define that only the validation response (which includes the validation score obtained from biometric server) should be stored in the signed PDF, instead of storing the entire biometric data. In this case, the document itself does not store the data required for a forensic examination of the handwritten signature, but legal considerations may result in preferring that option, in some countries.

For a local certificate signature, the sender can define filters on certificates to be offered for signing. Currently it is possible to define a preferred signature algorithm. Certificates using this algorithm will be ranked higher in the certificates offered to the signer.

The sender can also enforce to use the selected (preferred) one, which avoids that the signer is using certificates based on another (probably weaker) digital signature algorithm. You can enable preferred hash algorithm and enforce the use of the chosen algorithm. The enforce shown algorithm will be dynamically changed if the preferred algorithm is changed.

Options available for all signature types

In the section "Display following stamp imprint data", the sender can define which data to be contained on the signature representation on the PDF. Note that some items will be ignored when defining a custom stamp imprint configuration that simply does not contain a specific field for all or some signature types.

The following default values are used for all signature types:

Please note: If "Extra Information" is disabled, all other variables (such as "Name", "IP address" etc.) will be automatically disabled as well and no information will be displayed as stamp imprint. 

  • Signature rendering
    • custom signature image: false
  • Stamp imprint settings
    • Extra information: true
    • Email address: true
      The signer's mail address, automatically filled with the information available on the activity.
    • Transaction Id: true
    • Transaction token: true 
    • Phone number
      Automatically filled with the information available on the activity, when applicable. Always printed in the international format with country prefix (e.g. +39 or +43)
    • IP address: true
    • Name: true
      the full name (given name and family name) of the signer, automatically filled with the information available on the activity.
    • Signature date: true
    • Font name: Configured organization default is used
    • Font size: Configured organization default is used
  • Exceptions for Draw2Sign:
    • "Extra Information", "Display Email Address", "Display IP Address", "Display Name", "Display Signed on Date" is used from the organization default settings (configurable in the Organization dialog under "Extended settings for 'Draw to sign')

A-Trust signature type can now be configured in the UI.

Note: For the A-Trust signature configuration you need an A-Trust Signaturbox first. For more information please contact us.

Further information: A-Trust Guide (restricted access)

BankId signature type can now be configured in the UI.

For more information please see: WSC HOWTO BankID Plugin (restricted access)

The BankID implementation we are talking about here is the Swedish BankID implementation. The BankID is a common identification method provided by a consortium of the Swedish banking sector, and the identities (which are bound to the national unique number of a citizen) are linked to confirmed identities based on Anti-Money-Laundry verifications. For that purpose, a local device (Mobile Device with BankID App, or Desktop PC with installed BankID Desktop application) has to be installed. The app or application on the local device has to be linked uniquely to the confirmed identity. In addition, the service offers a signing method to sign with a signer-individual certificate provided by the Swedish BankID consortium.

It can be used both as authentication method (when opening a workstep / signer activity), and as signature type on a signature field level.

Feature Release

eSignAnyWhere 22.28

Date: July 2022

Beside, focusing on stabilizing and improving existing features to make them even better to use, following new features are available with this version:

It is now possible to choose between the following validity times for disposable certificate:

  • Regular disposable
  • Lean disposable with validity of 60 min
  • Lean disposable with validity of 30 days

It is possible to either change the validity in the web UI:

or it can be changed in the _global.xml (for more information please have a look at the RemoteSignaturePlugin - restricted access).

<!-- Defines the type for disposable certificate (Overridden by customization service) -->
<DisposableType values="Disposable;LeanDisposable;LeanDisposableExtendedValidity">Disposable</DisposableType>

A complexity check is now available for the signature type Draw2Sign. Please see the following sample configuration ( for a complexity check:

          <!--Minimum count/amount of packets for a signature. Default is empty value or 0 => All signatures are accepted in terms of length-->
          <variable name="SignatureComplexity_Draw2Sign_MinimumPackets" value="0" comment="Minimum count/amount of packets for a signature. Default is empty value or 0 => All signatures are accepted in terms of length" category="global/ViewerPreferences/SignatureComplexityChecks/Draw2Sign/MinimumPackets" />
          <!--Minimum time in milliseconds for a signature. Default is empty value or 0 => All signatures are accepted in terms of duration-->
          <variable name="SignatureComplexity_Draw2Sign_MinimumTimeInMs" value="0" comment="Minimum time in milliseconds for a signature. Default is empty value or 0 => All signatures are accepted in terms of duration" category="global/ViewerPreferences/SignatureComplexityChecks/Draw2Sign/MinimumTimeInMs" />

Please note that in the given configuration all signatures are allowed without checking time and packets.

LTS Release

eSignAnyWhere 21.76 ("22 LTS")

Date: May 2022

LTS version based on the feature release version 21.52.

Feature Release

eSignAnyWhere 21.52

Date: February 2022

The focus of this release is on stabilizing and improving existing features to make them even better to use. Please see all improvements in the following overview:

  • It is now allowed to have multiple identity providers in use for a single recipient. Please note that this is only allowed if the providers have a completely identical set of update rules.
  • Nested JSON in JWT are now also accepted by the OAuth2 checks.
  • The separation is now more visible between the OAuth2 Authorization Providers and the OAuth2 Identity Providers. In detail:
    • In the OAuth2 Authorization Providers list you will now only find OAuth2 providers with just validation rules
    • In the OAuth2 Identity Providers list you will now only find OAuth2 providers with at least one update rule
  • Stabilization of OAuth2
    • Stabilization of the OAuth2 provider authentication via api.
    • The template which was created from an envelope with OAuth2 configuration now also includes the OAuth2 configuration from the original envelope.

For more information about the OAuth2 configuration please have a look at the OAuth2 guide and for samples please also see the OAuth2 sample guide.

  • Additionally to the hash of the finished envelope you can now also find the hash of the initial document in the audit trail
  • The audit trail now also contains the eSAW version information
  • The audit trail sealing now considers PAdES signature level.
  • Stabilization of the audit trail
    • You can now find information about the OAuth2 authentication in the audit trail.
    • Timezone formatting issue fixed.
    • Chinese characters are now supported to be displayed correctly in the audit trail.

For more information about the audit trail please see the electronic signature guide.

There will no longer appear exceptions if a document is uploaded with predefined syntax which do not meet the requirements. Instead you will get the following warning:

You can either proceed with the uploaded document or cancel the upload.

For more information about the field markup handling in general please see the following guide: Field markup

Feature Release

eSignAnyWhere 21.31

Date: October 2021

You can now also configure JWT for the OAuth2 authentication for user authentication and signer authentication. For more information please see the How to configure OAuth2 authentication. For OAuth2 samples please see this guide. In this guide is also a ID Austria sample with JWT documented.

Document browsing is now also supported for the devices listed above. Please note that the feature is disabled per default but can be configured either in the SAW viewer global.xml or in the customization service.


 <!-- Defines whether or not to enable document view on some specific compatible signature pads (e.g Wacom STU 520/530/540, NT5010 or some StepOver devices)
           'useDocViewMonitor': defines whether or not to use a 'doc view monitor' upon using specific compatible devices (e.g. Wacom STU 520/530/540, NT5010) -->
      <DocViewModeEnabled useDocViewMonitor="1">0</DocViewModeEnabled>

Customization Service:

  <!--Defines whether or not to enable document view on some specific compatible signature pads (e.g Wacom STU 520/530/540, NT5010 or some StepOver devices)-->

   <variable category="global/SignificantDriverConfiguration" comment="Defines whether or not to enable document view on some specific compatible signature pads (e.g Wacom STU 520/530/540, NT5010 or some StepOver devices)" value="0" name="DocViewModeEnabled"/>

   <!--For 'DocViewModeEnabled': defines whether or not to use a 'doc view monitor' upon using specific compatible devices (e.g. Wacom STU 520/530/540, NT5010)-->

   <variable category="global/SignificantDriverConfiguration" comment="For 'DocViewModeEnabled': defines whether or not to use a 'doc view monitor' upon using specific compatible devices (e.g. Wacom STU 520/530/540, NT5010)" value="1" name="UseDocViewMonitor"/>


This feature allows signers to upload their picture (custom signature picture) and add it as additional graphics to the stamp imprint. Furthermore signers can store the signature image within a gallery for later usage. For more information please see the following documentation: Use external signature image

All dialogs support now keyboard usability.

Please note that the actual functionality of the keypress depends on the context of the dialog!

"ESC" keypress

  • closes the dialog
  • stops additional tasks if required

"Enter" keypress

  • activates the primary button, when no other action is required in the dialog
    • e.g. "Finish" dialog

"Tab" keypress

  • to navigate to the next element

For more information about the keyboard usability and about other aspects of the accessibility please see this guide.

The generic signing plugin is now also available for short time certificates (one time, one shot,  disposable etc.).

For more information about the generic signing plugin please see the release notes 21.16. For detailed information about the REST configuration of the generic signing plugin please see this guide.

With eSAW 21.31 we introduced, as part of a bugfix, a more strict phone number validation. For example: SMS-OTP authentication, the phone number must be provided in international format (+xxyyyyyyyyyyy) where +xx is the country prefix, and yyyy is the phone number inclusive carrier prefix (different length of country prefix and phone number are supported). The  use of phone numbers without country prefix - which did not return an error via REST Api, but did not lead to successful delivery in many cases - cannot be supported any longer as it was not determined which country is used.

Documentation change

Date: September 2021

Detailed documentation about how to configure SAML authentication for user authentication and signer authentication has been updated in the following guide: SAML Guide.

Documentation change

Date: August 2021

The documentation about metadata and the AdditionalClientWorkstepInformation has been updated in the following guide: Beginner Guide

Feature Release

eSignAnyWhere 21.27

In preparation

Date: Expected 24 August 2021

We improved again the performance of our solution to provide you an excellent user experience.

The identity settings providers moved to a separate configuration page. Those settings can now be found in Settings → Identity Providers. Please also see the next figure:

The SwissCom OnDemand Certificate is now also available in the UI. You can find the settings for the SwissCom OnDemand Certificate in Settings → Organization.

The settings for the recipient can be found on the create envelope page. There you have to fill in the mobile phone number, the country of residence and the organization (optional).

After these configurations you can use the SwissCom OnDemand Certificate as signature field in the UI:

Moreover, you can create a SwissCom OnDemand certificate signature field with Advanced Document Tags.

Just add the following code to your document to place a SwissCom OnDemand certificate signature:

[[!sigField1:signer1:signature(sigType="SwissComOnDemandCertificate"):label("some label"):size(width=150,height=60)]]

For general information about the advanced document tags please see: Use Advanced Document Tags to insert Form Elements or Signature Fields

The recipient who has to view the document was renamed to "Must view" recipient instead of "Acknowledge" recipient. For example:

Feature Release

eSignAnyWhere 21.16

Date: April 2021

Please note: For detailed information about the 21.16 features please also see this release notes document.

The feature implementation change of envelope expiry allows to specify absolute expiration timestamps (date and time), beside relative expiration date. For the relative expiration date, it allows specifying days, hours and minutes instead of just days. An expiration of less than one day is now supported. This enables senders of an envelope to set the exact expiration timestamp of an envelope, e.g. for offers valid just till an exact time like midnight.

Organization administrators can now customize localization (especially text translations) per organization. It enables a higher level of customization and more adjustments of the SignAnyWhere Viewer (Signer Front-End). The front-end can now be adjusted to the company’s common wording.
The organization administrator can now define filters on intended-use of certificates, for envelopes containing local certificate (SmartCard) signing experience. With that filter configured, the list of selectable certificates can be restricted to the certificates relevant on a local market (e.g. if a local signature smartcard contains two or more certificates for different purposes, like signing and identification).

With release 20.14 a year ago, the REST API Versions /v1 and /v2 have been marked as obsolete/deprecated and a migration guide has been published. With the 21.16 release, those versions have been removed:

• /api/v1 (also accessible via /api/v1.0)
• /api/v2 (also accessible via /api/v2.0)

The REST migration guide, which contains also some more information about the different API versions and in particular about the differences from version 1.0 or 2.0 to newer versions, is available here:

Migration Guide

Please mind that the guide describes the migration to v4, but similar functionality will also be applicable for a migration to /v5. The swagger documentation, which is our REST API reference documentation, is available here:

When storing signed documents in a document management system (DMS), a tagging of the document(s) is common and mandatory to find the document again. While eSignAnyWhere already supported providing metadata in API integrations, older versions allowed the sender via WebUI to specify just one free-text metadata field with the recommendation to put an XML structure into it. Since 20.52, it is possible to integrate custom tagging implementations, which consider structures and allowed values predefined in a DMS. It allows organization admins to define a custom page, being presented to the sender before sending an envelope for signing.

The UI of a metadata tagging form (or other before-send redirect page) can be aligned to the eSAW UI look and feel, or be aligned e.g. with your DMS. Consequently, the new change now allows defining metadata in templates. This can be used to set defaults, which are considered in a custom tagging page when a template was used to create the draft. Beside DMS tagging, metadata can be used also to define other values necessary for post-processing by a callback handler. Any additional information/description can be added into the metadata section of an envelope.

A new dialog will let you choose between bulk recipients added in an envelope draft and bulk recipient list defined in a template. For example: If you add a template with a bulk to an envelope which already has a bulk included you will be asked if you want to continue with the bulk from the template or with the bulk from the envelope. This will help you with the process flow of bulk sending as you can now differentiate between the bulks of different envelopes.
With custom signature rendering layout configuration (stamp imprint configuration), an organization administrator can define how the stamp imprint on the signature image looks like (e.g. fonts, elements, layout etc). The new functionality allows to set organization wide background images (e.g. company logos) or define specific fonts for text added to the stamp imprint. While it has no impact on the legal levels of signatures (in EU, defined by eIDAS), a customer specific stamp imprint representation can create higher subjective trust and contract awareness of your customers.
This feature clears up ambiguities in the UI. Only those features are displayed which are actually possible with the given settings. Non-accessible features will be hidden to optimize the UI experience.
The “Generic Signing Plugin” (GSP) allows implementation of custom 3rd party signature creation implementations (HSM based, web service based, etc). It is typically used to integrate external CAs into eSignAnyWhere. A GSP based implementation of a 3rd party CA is available for envelopes created via eSAW API or via eSAW WebUI. New features and improvements allow wider usage of the GSP.

LTS Release

eSignAnyWhere 20.76 ("21 LTS")

Date: April 2021

LTS version based on the feature release version 20.52.

Feature Release

eSignAnyWhere 20.52

Date: December 2020

You can now create, update and send a draft via API. Therefore, with the new API calls you can prepare an envelope and send it at any time. Before sending you can also update the draft if some configuration should be changed.
For more information about how to create and send a draft via API please have a look at the following guide: Use Case Example Draft

You can now configure the following viewer preference: AcceptAgreementDisabledUntilRequiredActionsDone

Note: You can configure the viewer preference in the UI in the section organization->design of the document viewer. Download the design template or your current design and set the variable AcceptAgreementDisabledUntilRequiredActionsDone to 0,

to disable this preference or to 1, to enable this preference. You can also configure this viewer preference via API. Therefore, just add the following variable in the section viewer preferences like it is shown in the next sample:

"ViewerPreferences": {
          "AcceptAgreementDisabledUntilRequiredActionsDone": true,
          "VisibleAreaOptions": {
            "AllowedDomain": "*",
            "Enabled": false
          }         },

Please also make sure that the "Allow Electronic Record and Signature Disclosure" is enabled:

If the preference is set to true and the agreement configuration is enabled the signer will then see the following interface before accessing the document:

On-premise only.

Organization Export

Allows you to export an organization’s settings and use it to create/update other organizations. Organizations can be exported, created and updated using the DB Manager or Admin Web. The result of the export operation is a Zip file that holds 3 files as follows:

  • Logo – The organization logo. (If the organization has no logo, then this file will be missing from the Zip file)
  • – Customization file of the organization. (If customization is not allowed for the organization, then this file will be missing from the Zip file)
  • ExportedSettings.xml -The actual settings of the organization in XML format.

Organization Import

There are two options for organization import:

  • Create new organization using the exported data of other organization.
  • Update an existing organization with the exported data of other organization.

The update process will skip updating the settings below (even if they are in the xml file) since they can affect ongoing/draft envelopes.

  • OAuth settings
  • Saml settings
  • Bank Id settings
  • SwissCom settings
  • Disposable certificate settings

Note: Data such as envelopes, address book etc. are not supported with the export/import of the organization.

eSignAnyWhere and SSP from now on separates between an “anonymized” and a “full” log file. On-Premise customers can share with us e.g. for analysis purposes the anonymized log file. Whereas offering SaaS, where anyhow a data processing agreement should exist, Namirial still has access to both log files but it allows sharing the non-anonymized log file with more people inside Namirial while the logs which contain personnel information will still be accessible only for a very restricted number of employees.Note that messages in log files and the error text returned e.g. in API calls (but not the error codes) will change in order to be more data privacy friendly.

If you use lean disposable via API, you have to provide the document issuing country instead of the country of residence. Therefore, we introduced the DocumentIssuingCountry via API. For compatibility with existing implementations, we allow to use the field CountryOfResidence but for legal reasons you also have to provide here (when using lean disposable) the country which issued the identification document.

If you do not use lean disposable (but consider that the “traditional” non-lean disposable should be used only in exceptional cases), you have to continue using the field CountryOfResidence as in the past.

Documentation change

Date: November2020

The Beginner Guide has been expanded to include the following:
In the section “signatures” you can now also find an example (REST/SOAP) of a StampImprintConfiguration.
The Use Case Example Template has been expanded to include the following:
In the section “Override Radiobutton” you can now find an example (REST/SOAP) of how to override a radio button from a template.

Feature Release

eSignAnyWhere 20.42

Date: October 2020

This plugin provides a generic way of integrating external (remote) signatures. Please see the following supported features:

  • Signing types (defined by the plugin implementation)
    • User signing
    • Batch signing
    • Automatic signing
  • Authentication
    • Using dynamic data fields
      • Types: Text, Phone number, Number, List (dropdown), Email, Password
    • Using external system (redirection to external URI)
    • Using external app (e.g. push notification) + callback receiver
  • Signing method
    • Hash signing only via the plugin
    • Hash signing only via the default SSP integration

For more information about the configuration in the UI please have a look at the Electronic Signature Guide, the Signer Guide and the User Guide.
For more information about the configuration with REST API please have a look at the Beginner Guide. There you can find a sample configuration.

Previously the API authorization consisted of two parameters (OrganizationKey and UserLoginName). This has been reduced to a single parameter; an API Token. This token is individual for each user and can be created/updated/disabled/deleted on a new Page (ApiToken/Index->My Tokens). A user can have multiple API Tokens that allow a more granular usage of them. For example one token for integration A and another token for integration B.

Note: If a token is deleted it can not be recreated with the same token value.

Two possibilities for authentication:

  1. Using the new API Token header (REST) or the API Token XML node (SOAP). Here
    only the API token is a valid value.
  2. Use the OrganizationKey and the userLoginName for the authentication

For more information about the

You can now also use the driving license as an identification type. This new identification
type is available in the UI as well as in the API.

For more information about the disposable certificate please also have a look at the Beginner Guide.

We improved again the performance of our solution to provide you an excellent user experience.
We declared SOAP as deprecated and therefore SOAP will not be included in versions after 21.76 (already postponed by one year, initially the 20.76 was announced). Latest release including SOAP API for eSAW will be 21.76, released in spring 2022 and with the software maintenance on 21.76 until spring 2024.
Therefore, we recommend REST technology for integration. Please see also the migration guide.

The bulk signing assistant is a feature that allows you to sign multiple documents with one click.

Note: The bulk signing assistant (eBSA) currently does not support the full set of features of eSignAnyWhere envelopes and signature methods. It is limited to

  • Envelopes without authentication
  • Envelopes that use Click2Sign as the only signature variant
  • Only envelopes that do not require confirming an agreements dialog (Terms&Conditions) first

Please see also this guide: Bulk signing assistant

Feature Release

eSignAnyWhere 20.28

Date: July 2020

We declared SOAP as deprecated and therefore SOAP will not be included in versions after 21.76 (already postponed by one year, initially the 20.76 was announced). Latest release including SOAP API for eSAW will be 21.76, released in spring 2022 and with the software maintenance on 21.76 until spring 2024.
Therefore, we recommend REST technology for integration. Please see also the migration guide.
In addition to the predefined roles and permissions you can now define your own roles. So, for example you can define a new role, where the user can manage and send envelopes, but not create the envelopes on their own. Or a role which can configure automatic remote signatures themselves, without being user managers. Moreover, you can also set the permissions for your roles.
For more information please have a look at this page.

You can now find the setting in your organization to lock form fields. If you prevent editing form fields after the envelope is finished the form fields in the PDF are all read only. Therefore, after locking the form fields (after the final workstep), the form fields are not editable any more with other PDF tools.
For more information please have a look at this page.

You can also lock form fields with the API. Therefore, just add the following before the node “steps” in REST:

"LockFormFieldsAtEnvelopeFinish": true,

Or in SOAP:


In your organization settings you can now select required authentication methods. You can either select any or a specific authentication.

Moreover you can set the following

  • Force input of the phone number when using SMS-OTP authentication
  • Allow skipping forced authentication upon using biometric signatures
  • Allow skipping forced authentication upon using disposable certificate, remote certificate or local certificate

For more information please have a look at this page.

You can find this feature in your organization settings in the section “Testing Phase Features”.
There you can allow to copy the viewer link from the envelope details page. If the user signs the envelope via the copy viewer link, then this information is also shown in the audit trail.

For more information about the clipboard please have a look at this page.

You can now configure a bankID signature field and a bankID authentication via api.
For more information about bankID and the configuration please have a look at this page.

Feature Release

eSignAnyWhere 20.14

Date: April 2020

You can now define hyperlinks for your document with API. The next lines of code show you a sample configuration of one hyperlink:

"HyperLinks": [
		 "Id": "c238bd01-78ca-4958-a6dc-957fed629aa0",
		 "DocRefNumber": 1,
		 "PositionPage": 1,
	         "Uri": "",
			"Position": {
				"PositionX": 346.0,
				"PositionY": 707.0
			 "Size": {
				"Height": 15.0,
				"Width": 152.0

For general information about the hyperlinks please have a look at: Hyperlinks

The email template configuration in the product changed. Also some new placeholders were added. For more information please have a look at: Settings and Customizing

or in the product in the following section: Settings->Email Templates, there you will find a new section with all possible placeholders for each template. You can copy the placeholders and past it in your template.

The sender of an envelope can define wether the recipient of the envelope has access again after finishing and closing the envelope. For more information about the process of opening documents and finishing them please have a look at: Signer Guide

We improved again the performance of our solution to provide you an excellent user experience.

Links are now supported in the disclaimer dialog. For  more information please have a look at: Beginner Guide

We recommend REST technology for integration. However, we will offer SOAP as well and SOAP is still being maintained. When we decide to declare SOAP as deprecated in the future, we will publish further information on this page. In this case, we will grant enough time before SOAP gets discontinued.

LTS Release

eSignAnyWhere 19.76 ("20 LTS")

Date: April 2020 (Release Candidate)

LTS version based on the feature release version 3.7.

Feature Release

eSignAnyWhere 3.7

Date: January 2020

You can now choose between the following five configurations for a Batch signature:

  • Simple Batch
  • Signature List (unselected)
  • Signature List (preselected)
  • Signature List (selected, required mandatory)
  • Signature List (unselected, required mandatory)

We added the last two modes for mandatory fields (selected and unselected). This makes it possible to distinguish between mandatory and voluntary fields.

Therefore, the selected means that the user can select/deselect only signatures which are not required. All signatures are initially selected. The unselected means that the user can select/deselect only signatures which are not required. All non required signatures are initially deselected.

For more information please have a look at Signer Guide

PAdES configurations were added to the organization settings. There you can choose between the following levels:

  • B
  • T
  • LT
  • LTA

For detailed information please have a look at Settings and Customizing

There you can find all descriptions for the different levels.

You can now configure an A-TRUST signature in your workstep configuration. For more information please have a look at the Beginner Guide

In this guide you can also find a sample configuration for an A-TRUST signature.

If you are using eSAW on premise or in a private SaaS and use the SIGNificant Kiosk, you can use new features now:

  • Combobox
  • Listbox

The API caching now returns cached results in the case the same request is executed again too fast (e.g. after just some milliseconds).

We improved again the performance of our solution to provide you an excellent user experience.

Feature Release

eSignAnyWhere 3.6

Date: September 2019

The viewer supports new batch signature options, where the signer gets a list of the batch signature, either preselected or deselected. The original batch signature dialog is still available.

The new license management allows you to set warning notifications if the license or the envelope limit expires. You can even set a callback for an envelope limit warning.

If you are using eSAW on premise or in a private SaaS and use the SIGNificant Kiosk, you can use new features: SMS-OTP, Disposable and a PushTan integration.

You can easily change now holder information and validate the information in advance.

If you are using callbacks for your integration, you can set now basic authentication for your callbacks. Moreover, you define a pattern to define different callback-authentications.

The SAW Viewer allows now a local certificate verification.

We improved again the performance of our solution to provide you an excellent user experience.

Feature Release

eSignAnyWhere 3.5

Date: July 2019

We redesigned the SAW Viewer to enhance the usability and user experience. For more details check the special SignAnyWhere Viewer 2019 page.

We optimized the usage of the disposable certificate and how it is integrated.

We reworked the team feature, due some customer feedback. We optimized the sharing between teams, to prevent the sharing of all documents of two (or more) teams with a shared team-member. Moreover a hierarchy is now possible: (1) see all documents up & down or (2) see documents only down (“team lead”, but not seeing sent documents of my manager).

You can now view and export your organization’s statistics in the license section of the settings (accessible for user managers).

You can now access the license data via API. For SOAP we have the GetLicenseState_v1 and for REST V4+ V4/license. The response will be the type of the license, expiration date, status about the documents and users.

We added a new API call to unlock a parallel recipient to be opened by others again. Older versions only allowed it manually via UI, now you can integrate or automate it yourself. SOAP is called UnlockEnvelope_v1 and REST is called V4/envelope/{envelopeId}/unlock.

We added a new SAW Viewer Policy AutoStartGuiding, which allows you to start automatically the integrated guiding. This enables a use case, where the document loads and directly jumps to the first signature field.

We improved the UI of eSAW to allow a better user experience (e.g. license page).

We changed the default email template to a new one. For existing organizations, the set template will not be changed, just for new organizations or if you reset the template.

Feature Release

eSignAnyWhere 3.4

Date: February 2019

We integrated the Swedish BankID for authentication. Please contact us if you want to know more about it.

We improved the overall systems performance (database optimization, document processing, data management).

You can now optionally attach the document to the audit trail. So you have the final & signed document as PDF attachment in the audit trail. Note: this will increase the size of the audit trail.

This feature is only available via API in the <envelope> section, per default it is disabled (0).


You are able to overwrite the signature disclosure (set up via eSAW UI in the organization settings) via API. So you can define unique information per envelope or recipient (e.g. for internal users disable the signature disclosure).

This is configured via API in the <step> section of the envelope.


useDefaultAgreements – true (default value): use the default signature disclosure of the organization (the configuration in the workstepConfiguration is ignored)

useDefaultAgreements – false: use the setting of the workstepConfiguration (overwrite). If the config is empty, no signature disclosure is set for the recipient.

Optimization of the on-premise setup of eSignAnyWhere.

Improvements of SAW Viewer

  • Optimized mobile OTP forms
  • BankID support
  • Added check for enabled cookies
  • Added disposable certificate disclaimer text (FR/PT)
  • New languages: Polish, Chinese
  • Security enhancement
  • Fixed QR code for SoP (had some issues with some browsers)
  • Optimized tablet view of the menu
  • Optimized image generation for Click2Sign, Draw2Sign and Type2Sign

via Hotfix

  • Reject message can be empty
  • FinishAction also for Reject and Delegate
  • fixed Translation issues

Feature Release

eSignAnyWhere 3.3

Date: November 2018

The security of your documents is in our primary focus. Therefore, we improved the security of eSignAnyWhere to ensure the security of your documents.

We improved the overall performance of eSignAnyWhere for excellent user experience and increased scalability to grant you high performance, even in critical high load scenarios.

Improvements for point of sale use cases. This includes for example optimizations for timeouts in the clients and data handling for fast responses in a workflow.

eSignAnyWhere allows you to define a logout redirect page. So you can integrate eSAW in your intranet applications and set a specific logout page for your users.

We improved the installation procedure for on premise installations of eSignAnyWhere.

We added for API use cases the support of SwissCom certificates (personal and organization certificates).

  • Security Improvements (CSS, Input Validation, brute-force PIN prevention)
  • Visual optimization of the disposable certificate form
  • New Language: Bulgarian
  • New viewer preference: PhoneNumberInputSettings
  • Technical: switched to XLIF format for language support
  • fixed some UI bugs

via Hotfix:

  • fixed Draw2Sign & Type2Sign placement
  • fixed QR code for SoP for some browsers

Feature Release

eSignAnyWhere 3.2

Date: August 2018

It is possible (as advanced feature) to use automatic remote signatures. The user manager of an organization can add automatic remote signature profiles, which can be used for any workflow as a recipient (recipient type “Automatic”). This recipient signs automatically the signatures and the workflow continues automatically. Details see Beginner Guide.

It is possible to use the replace recipient method (ReplaceRecipient_v1) to change the workstepconfiguration. It is only possible to change the workstep configuration if the envelope was created via API and the recipient is a signer.

eSignAnyWhere 3.2 now fully supports the SIGNificant Biometric Server for signature verification, including the SignAnyWhere Viewer and the audit trail file. This feature is not available on and requires a private SaaS or on premise instance of eSignAnyWhere.

The SAML support was extended to allow easier user management directly in the UI of eSignAnyWhere. SAML requires a private SaaS or on premise instance of eSignAnyWhere.

Automatic Delegation is an advanced feature, which allows the user to define an automatic delegation. So all of the user’s signing requests are automatically forwarded to a substitute, which is also a user of the organization. An optional end date automatically disables the automatic delegation.

  • UI optimized resizing of window behavior
  • Open source information added in the SAW Viewer
  • Fixed biometric signature under certain use cases
  • Optimized UI for authentication
  • Error handling of uploading attachments improved
  • Improved error messages
  • Device Driver UI optimized
  • bugfix for batch signature

via Hotfix:

  • fixed some translations
  • fixed navigation bar, when maximizing window
  • fixed rejecting of document for specific use cases

Feature Release

eSignAnyWhere 3.1

Date: May 2018

Bulk envelopes allow you to send an envelope to multiple signers. The workflow splits with the bulk recipient, so that you will receive unique signed documents for each bulk recipient. This feature is perfect for letting one document (e.g. a new company policy) sign by many recipients. This feature is not available with basic subscription, so please contact your Namirial sales. Details in the Bulk Use Case.

It is possible to define P7M signers in eSignAnywhere. This allows you to define at the end of a signing workflow to define signers with P7M. Details see in the Beginner Guide.

In addition to our SOAP interface a new REST/JSON Swagger interface is available. See

Added support for Form-Field-Validation. Six types are supported: No-Validation, Date, Email, Number, Phone and Time. It is only supported with the Placeholder Use Case and via workstep configuration.

The Retention Period per organization sets an automatic timelimit for deleting old envelopes.

You can select now the email sender name. In the organization settings you can select between three options: (1) firstname lastname via eSignAnywhere (2) Organizationname via eSignAnywhere (3) eSignAnywhere. On-premise or private SaaS customer can replace eSignAnywhere with their desired text. Via API you can select the option for each envelope.


If the displayedEmailSender is empty only eSignAnywhere is used. If the field is not empty, this text will be used before ” via eSignAnywhere”. Without displayedEmailSender the organization default setting is used.

  • form field validation
  • added undo option
  • added languages: Spanish, Portugese
  • updated translations
  • improvements for local certificate signing
  • allow configuration of date format for picture signature types
  • fixed UI issues for some devices (mobile, tablet or browsers)
  • fixed device driver issues
  • fixed attachment with hidden documents
  • fixed Finish button visibility after finished document
  • fixed error for some specific policies
  • fixed the guiding for disabled elements
  • fixed local time issue

via Hotfix:

  • fixed a finish document issue
  • fix batch signature with OTP issue
  • optimized Device Driver integration

Feature Release

eSignAnyWhere 3.0

Date: February 2018

With this feature you are able to hide specific documents from specific recipients. So you can create an envelope with two documents, where the first signer just can see the first document, the second signer only the second and the third can see all documents. You can configure it in the eSAW UI or via API.

API Configuration is done via envelope/steps/step/documentOption; Sample:

             <documentOption docRef="1">
             <documentOption docRef="2">

This feature is not available in all subscriptions.

A new signature type is now available. You can define a signature field, which sends a SMS-OTP in the moment of signing to have a second factor for it. Basically, it is a Click2Sign with an SMS-OTP. You can select it via UI (SMS-OTP Signature Type) or via API:

    <phoneMobile>...</phoneMobile> <!-- naming consistent with "disposableCertificateAdditionalInformation" -->

Moreover, in the workstep config the type must be TransactionCode, with trModType set to TransactionCodeSenderPlugin.

This feature is not available in all subscriptions.

For on premise and private SaaS it is possible to configure custom links for notifications. So the workstepRedirector can support your apps to open directly the workstep. For more details contact your Namirial consultant.

Acknowledge recipients are included in the “send finished documents to all signers” checkbox in the eSAW UI (and it is renamed to support also acknowledge recipients).

If you are generating a workflow, where a recipient has to enter data and upload a file (as PDF attachment), you can now directly access the file via eSAW API. Call the getEnvelopeById function to retrieve information about the attachment and the file Id for downloading.

It is possible to set a behavior to confirm reading of a document.

Set in the WorkstepConfiguration (for a recipient) the following Task (in workstepConfigurationPolicyWorkstepTasks):

<Task enabled="1" completed="0" required="1" id="847a3d4a-da2c-46f4-8c8c-a9edaa06c29b" displayName="your text for this task" DocRefNumber="1" type="ConfirmReading" />

The task must be the first and required!

Then you have to create the ReadingTaskInfo (directly in the WorkstepConfiguration) with attribute AllDocuments=”1″:

<ReadingTaskInfo positionUnit="PdfUnits" positionReferenceCorner="Upper_Left">
	<ReadingTask id="847a3d4a-da2c-46f4-8c8c-a9edaa06c29b" pageNumber="1" DocRefNumber="1" AllPages="0" AllDocuments="1" />

You retrieve now also a callback, when an envelope expires.

The getEnvelopeById contains now more details about the envelope (e.g. recipient details, signing date and authentication).

Advanced document tags now support an offset, to define a relative positioning of the element. Offset is defined as number (double), in Units points and starts at the lower left position. Positive values x are moving to the right and positive values y are moving up. e.g.

  • support of hidden documents
  • support for confirm reading
  • reworked rendering of some signature types (local certificate, remote signature, disposable signature)
  • fixed OTP signature issue with wrong OTP
  • reworked zoom handling
  • fixed a delegation issue (delege to yourself)
  • optimized UI for devices (mobile, tablet, browsers)

via Hotfix:

  • fixed translations
  • reworked visual appearence of attachments
  • added new viewer policies for customization
  • fixed UI in landscape for mobile devices
  • fixed OTP handling & errors
  • fixed OAuth/SAML with a port in configuration
  • upgraded Device Driver protocol level
  • fixed a batch disposable certificate issue
  • enhancements for debug mode
  • client server communcation optimization (e.g. retry for calls)

Feature Release

eSignAnyWhere 2.6

Date: January 2018

The Audit Trail supports now different languages:

  • SignAnywhere Viewer (Signer-Interface): Audit Trail is rendered in the language of the viewer
  • eSignAnywhere UI: Audit Trail is rendered in the users UI language. Moreover it contains a language independent XML representation.
  • API: via API you can download a signed XML, containing the Audit Trail data (via GetEnvelopeById as logXmlDocumentId)

You can use SAML to authenticate signers in the SignAnywhere Viewer (Signer Interface). You configure the SAML provider and can use it via UI and API. Click here for details about the configuration for API. Contact your Namirial sales for enabling SAML support.

This feature is not available in all subscriptions.

Only private SaaS and on premise: each organization of the instance can have their own biometric encryption key.

It is possible to delete recipients of already started workflows, which did not yet sign the document. This is available in the detail view of an envelope in eSignAnywhere.

It is now possible to show a permanent reject button in the menu. This can be configured via customization with the new parameter DisplayRejectButtonInLeftBar.

With OAuth2 it is now possible to do an authentication check. So you can force that a specific userId has to authenticate via OAuth2 provider.

E.g. userId=123 of provider CustomOAuthService has to authenticate. If another user authenticates it is rejected. Just a user with userId=123 is accepted.

See Envelope XML Guide to see how you configure it via API.

This feature is not available in all subscriptions.

You can now, in addition to the envelope audit trail, download for each file a specific audit trail via API (GetEnvelopeById in section completedDocuments). You can enable it in the organization settings.

If you create an envelope within the eSAW UI, you can now download the complete envelope XML including the workstep configurations for your envelope. Therefore you have to be a “Developer”, which can be set up by a user manager in the account settings. Then you are able to download the XML at the end of the envelope-sending-process and in the envelope details page.

You are able to set a default callback URL in the Organization settings of eSAW. So you can send out envelopes via eSAW UI and perform an integration on your side (e.g. an automatic archiving of the documents).

Feature Release

eSignAnyWhere 2.5

Date: September 2017

New types of callbacks are now available. See documentation for details.

The on premise version of eSignAnyWhere supports now different organisations with just one instance.

Full support of SIGNificant device driver. So you can use now signature pads or local certificates with eSAW as a signer.

New eSAW Viewer settings are available. For example, you can define now to automatically finish a document when the last signature was applied or configure the download document dialog. See here for details.

The performance of eSAW was improved. For example is the generation of the Audit Log optimized and the envelope-postprocessing, if no email is sent, done with highest priority.

GetEnvelopeById contains the reason about rejection or delegation.



Feature Release

eSignAnyWhere 2.4

Date: July 2017

We added the support of PDF form fields in the designer. So you can add text fields, radio buttons, checkboxes, lists and many more directly in the designer by drag and drop. You can select the behavior similar to signature fields (select a recipient) and configure some properties of them. See the User Guide for more information.

New advanced tags are supported to predefine in the documents signature fields and form fields. They are more complex than the easy to use Signature Strings (see User Guide). The advanced tags are documented in the Placeholder Use Case. For the advanced tags a new API function PrepareSendEnvelopeSteps_v1 is available.

It is possible to use a template and replace the document of the template. The position of the fields (e.g. signature fields) are kept. See the User Guide for more details.

Registered signers are able to upload a picture of their signature (e.g. written on paper) and import it to eSignAnyWhere. eSignAnyWhere enables an editor to modify and adopt the signature (crop, rotate, cut) to be used as signature for signing. See User-Guide for more details.

To avoid filling up email postboxes, eSAW now sends the documents as attachments, as long as they are under 2,5 MB. If larger documents are used, just a link to the document is sent. This link is valid for 90 days to download the file.

You can now manage the users of your organisation via API. See API Reference - SOAP for more information.

You can now use the FindEnvelopes_v2 function for advanced search via API. See the API Reference - SOAP for more information.

For complex integration it is now possible to disable sending emails for a specific recipient (e.g. in a POS scenario). See Integration for details.

You can add now custom buttons in the signing interface (the eSAW Viewer) to add custom functionality.

We added some configurable settings, such as avoiding dialogs or settings for Batch-Signing, for the eSAW Viewer. So you can define the behavior of the signers-view. See this documentation for more details.

  • No labels