For information on our current and upcoming deployments, please see the Releases and Maintenances Calendar section of our Trust Center.

Release 26.R2: February 2026

Prev Next

Behavior Changes for this Release

Here are some of the changes in behavior introduced in this release that you might want to be aware of.

  • Improved API Access Page: To improve clarity and ease of use we have made some UI changes to the API Access page. (refs PB-120554)

Planned for a Future Release

Here are some of the new features, changes and enhancements that will be coming in one of our upcoming releases.

Expiring Signer Links (Security & Compliance Enhancement)

To strengthen access controls and support regulatory compliance requirements, we are introducing configurable expiration times for links to transaction that are sent to signers.

This enhancement mitigates the risk posed by long-lived URL links to transactions by limiting signer access to these links to a defined timeframe. Enforcing link expiration helps organizations align with industry regulations, internal security policies, and audit standards that require limiting access to sensitive documents to certain timeframes.

To avoid disrupting your existing workflows, the default value for expiring links will be unlimited. However, we strongly recommend defining a shorter-term value to enhance security and reduce the potential risk involved in allowing extended access to these links.

This feature will be introduced in the following releases:

  • Sandbox (26.R3): Available for testing. Please contact our Support Team to enable this feature for your account.

  • Production (26.R4): Available across all production environments as a self-service configuration.

Bounced Email Callback Changes

In our upcoming 26.R3 release we will be introducing the following changes to the email bounce callback: (refs PB-117208)

    • New Bounce Types: The following changes to email bounce types will be introduced:

      SES Bounce Type

      Current Behavior

      New Behavior

      Any hard bounce

      BOUNCE

      BOUNCE

      Complaint

      COMPLAINT

      COMPLAINT

      Soft bounce - AttachmentRejected

      OOTO

      ATTACHMENTREJECTED

      Soft bounce - ContentRejected

      OOTO

      CONTENTREJECTED

      Soft Bounce - General

      OOTO

      OOTO

      Soft bounce - MailboxFull

      OOTO

      MAILBOXFULL

      Soft bounce - MessageTooLarge

      OOTO

      MESSAGETOOLARGE

  • Changed class name for bounce callbacks: The class name in the callback will be changed from "com.silanis.esl.packages.event.ESLProcessEvent" to "com.silanis.esl.notification.BounceNotificationEvent".

  • New callback parameter: A new parameter (diagnosticCode) will be introduced in the callback with the details of the bounce message.

    • If you are interested in testing this new functionality, or if you need to update your integrations, contact our Support Team.

Sender Authentication Tokens

A new, optional Sender Authentication Token feature will be available in 26.R3. Currently, when you request a sender authentication token, you need to specify a transaction ID. The sender authentication token that is then generated can then be used to access that specific transaction or any other transaction available to the sender. Additionally, it can even be used to gain access to a full session.

In this upcoming release, a new account setting will be introduced which will allow you to restrict the access rights of the sender authentication token to just the transaction used to generate it.

To enable this feature, you will need to contact our Support Team. (refs PB-116234)

Additional Upcoming Changes

  • Sender as signer verification: To enhance the security of transactions, a sender that needs to sign will be required to authenticate if an authentication method for that sender is specified during transaction creation. Currently, a sender can proceed directly to the signing ceremony without additional authentication after logging into the sender portal. (refs PB-120921)  

  • Electronic Consent Document Language enhancement: The electronic consent document will now be automatically updated based on the selected transaction language, provided the consent document is available in that language. Currently, the consent document does not automatically update when the transaction language changes. To address this, a new consent API will be available for API-integrated customers. This API will ensure the consent document is synchronized with the transaction language, providing seamless updates. (refs PB-120922)

What’s New

Here are some of the new features and enhancements we have made for this release.

Authentication

  • Support for Multiple mTLS certificates when using Supporting Documents: You can now use mTLS (fingerprint) certificates with Supporting Documents. This applies to API calls only. (refs PB-119332)

Integrators

Integrators can now take advantage of the following new features:

  • Delegating management now available through .NET SDKs: You can now use .NET SDKs to create a session on behalf of another sender so that they can perform actions on their behalf. (refs PB-116763)

Signer Experience

  • Improved Signature Type options: We have added the ability to upload an image when Choose Signature is selected as a Signature Type. Signature types can also now be used when delegating a signer. (refs PB-121192)

  • Enforce Capture Signature now supported with Drawn signatures: Enforce Capture Signature rules are now applied to Drawn signature types (not applicable to uploaded images). (refs PB-116848)

Bug Fixes

The following issues were resolved in this release.

Authentication

  • We have fixed an issue where SMS authentication attempt limits were not applied when an invalid signer phone number was used. (refs PB‑119650)

  • Locked signers can no longer complete an ID Verification (IDV) attempt by using a previously opened browser tab. Instead, they will be redirected to the lockout page. (refs PB‑119650)

Integrators

  • We have resolved an issue that caused continuous polling requests after a 403 error, even when using the Cancel button. (refs PB‑120876)

  • Mismatches between the documented and actual sessionFields schema in the Interactive API documentation have been corrected. (refs PB‑121989)

Senders

  • Text in Text Area fields would fail to wrap correctly in the Designer. This behavior has now been corrected. (refs PB‑121003)

  • Transactions could not be resent when a signer included an optional signature field. Adding an optional signature no longer blocks transaction resending. (refs PB‑121627)

  • We have updated our internal SMS delivery configurations to allow SMS Notifications to be used in US Territories (Puerto Rico, Guam, US Virgin Islands, American Samoa, Northern Mariana Islands). Previously, attempting to use SMS Notifications in these territories would result in failed or undelivered SMS. (refs PB‑121937)

  • Signatures were attributed to the wrong recipient when the Designer was used within an iFrame. This no longer occurs. (refs PB 122105)

  • Adding a new ad hoc group recipient caused the signing order to be assigned incorrectly. The signing order now updates as it should. (refs PB‑122232)

  • We have fixed an issue where an error would be displayed about missing permissions when a user logged in with the required permissions. (refs PB‑123165)

Signer Experience

  • Using pinch‑and‑zoom actions on a mobile device caused the signature capture panel to open with an incorrect zoom, preventing signing. This has been fixed. (refs PB‑98292)

  • We have resolved a navigation problem where the Next button failed to move to the next signature when page sizing differed. (refs PB‑121241)

  • Supporting documents are now included in the downloaded package.zip from the In Person Thank You page. (refs PB‑122771)

Vulnerabilities

  • This release also includes important security and vulnerability fixes.