---
title: "Release 26.R3: April 2026"
slug: "release-26r3"
description: "Explore the 26.R3 release with improved API access, OAuth 2.0 authentication, and enhanced email bounce handling for better user experience."
status: "update"
updated: 2026-06-29T13:06:05Z
published: 2026-06-29T13:14:27Z
canonical: "docs.onespan.com/release-26r3"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.onespan.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Release 26.R3: April 2026

## 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

The [API Access page](/v1/docs/managing-api-access-and-authentication-settings) has been updated. Instead of using a single authentication method, you can now select multiple methods using new checkboxes. The API key has been moved to the **Authentication** tab, and a new **Client Apps** tab has been introduced to better organize related settings. (refs PB-120542)

![image.png](https://cdn.document360.io/038f59a7-abd0-4c14-9de7-3434d28b49fd/Images/Documentation/image(247).png)

### OAuth 2.0 Authentication now set by default

[OAuth 2.0 authentication](/v1/docs/managing-api-access-and-authentication-settings#oauth-20) is now automatically enabled for any accounts that were previously configured to use OAuth authentication. If your account was not configured to use OAuth authentication, contact our [Support Team](https://www.onespan.com/support) to enable it. (refs PB-120612)

### Bounced Email Callback Changes

The following changes have been made to the email bounce callback: (refs PB-117208)

- 
  - **New Bounce Types**: The following changes to email bounce types have been 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 has changed from "`com.silanis.esl.packages.event.ESLProcessEvent`" to "`com.silanis.esl.notification.BounceNotificationEvent`".
- **New callback parameter**: A new parameter (`diagnosticCode`) has been introduced in the callback with the details of the bounce message.

### UI and Other Changes

The following changes in UI behavior or appearance have been made:

- **Updated supported date formats**. We have updated the date formats that can be used by integrators. More specifically, capitalized years are no longer supported (for example, YYYY). Existing integrations will be automatically converted to the new format and will continue to work as expected. (refs PB-119667)
  - The new supported formats are:
    - yyyy-MM-dd"

“yyyy-dd-MM”

“MM-dd-yyyy”

“dd-MM-yyyy”
- **Updated header menu icons**. Several icons in the sender interface header have been refreshed for clarity and consistency. (refs PB-120976)
- **Hidden “esigned by” text for initial selections.** The “*esigned by*” label is no longer displayed on **Choose Initials** signatures. This was done to enhance clarity and readability. (refs PB-121239)
- **Warnings and errors no long auto‑close**. Users must now click the “X” to dismiss alerts, which improves accessibility compliance. (refs PB-121406)
- **Updated OFAC terminology**. To eliminate confusion, multiple labels and event names were rewritten to say “*Customer blocked country list*”. (refs PB-122329)
- **Fast Track link changes**: Fast Track links can now only be generated from templates. You can no longer generate these links for transactions. (refs PB-122512)
- **Default In-App Documentation**. The in-app documentation widget introduced in [Release 25.R4](/v1/docs/release-25r4-july-2025) is now enabled by default for all non-white labelled accounts (accounts that have not overridden the default Sender UI logo).

## 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.

**Sender as signer verification**: To enhance the security of transactions, a sender from a different account that needs to sign is now required to authenticate if an authentication method for that sender is specified during transaction creation. Previously, a sender from a different account could proceed directly to the signing ceremony without additional authentication after logging into the sender portal. Note that senders from the same account can still proceed directly to the signing ceremony. (refs PB-120921)

## What's New

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

### Expiring Signer Links

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](https://www.onespan.com/support) to enable this feature for your account.
- **Production (26.R4)**: Available across all production environments as a self-service configuration.

### Sender Authentication Tokens

A new, optional Sender Authentication Token feature is now available. Previously, when you requested a sender authentication token, you needed to specify a transaction ID. The sender authentication token that was then generated could have been used to access that specific transaction or any other transaction available to the sender.

This release introduces a new account setting 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](https://www.onespan.com/support). (refs PB-116234)

### Notification Improvements

The following improvements have been made to our Notification features:

- **SMS-only notification for transactions**. In addition to email, email + SMS, senders can now choose SMS as the sole delivery method when creating a transaction. Note that a recipient email address is still required for the transaction. (refs PB-121265) ![Notification settings for selecting SMS as the preferred method of contact.](https://cdn.document360.io/038f59a7-abd0-4c14-9de7-3434d28b49fd/Images/Documentation/SMS Notification.png)
- **Added control over notifications for unauthenticated signers.** Added an account-level setting to suppress notifications for signers without authentication, improving message control. (refs PB-123469)

### Electronic Consent Document Language Enhancement

The electronic consent document is now automatically updated when a transaction’s language is changed from the sender interface, provided the consent document is available in that language. Previously, the consent document would not automatically update when the transaction language changed. In addition, a new consent API is available for API-integrated customers. This API allows client applications to change the language of an existing transaction’s electronic consent document. (refs PB-120922)

### Improved API authentication flexibility

You can now choose multiple authentication methods for API calls. The [API Access page](/v1/docs/managing-api-access-and-authentication-settings) has been updated with checkboxes for method selection, a relocated API key under the **Authentication** tab, and a separate **Client Apps** tab. (refs PB-120542)

### Template Import and Export

We have introduced new template import and export capabilities within the Sender UI. This significantly enhances the user experience by allowing users to easily transfer templates between different accounts, ensuring that they can access and use their preferred designs across multiple accounts. (refs DAG-301)

![](https://cdn.document360.io/038f59a7-abd0-4c14-9de7-3434d28b49fd/Images/Documentation/image(248).png)![](https://cdn.document360.io/038f59a7-abd0-4c14-9de7-3434d28b49fd/Images/Documentation/image(249).png)

> The following features are not retained or supported when importing and exporting templates:
> 
> - Supporting documents
> - Remote Online Notarization settings
> - IPEN settings
> - IDV settings
> - Groups

### Additional New Features

- **Conditional Logic Enhancement.** You can now create conditions across signature fields belonging to different signers. To enable this feature, contact our [Support Team](https://www.onespan.com/support). (refs PB-119959)
- **New mobile signing options for signature and initials selection.** We have enhanced our **Choose Signature** and **Choose Initials** signature types with the following: (refs PB-121912)
  - Mobile users can now sign using the **Choose Signature** and **Choose Initials** options,
  - You can now set a preferred signing method (style, draw, upload, mobile),
  - The new signature styles are now supported with Java and .NET SDKs.
- **Accessibility Improvements**. The **Required** and **Optional** signature previews now use 80% opacity to match the signing ceremony, and the color contrast checker now accounts for this when validating accessibility compliance. (refs PB-123922)
- **Improvements to Fast Track usability.** The [Fast Track](/v1/docs/fast-track) page now follows the template language by default, and the order of first name/last name fields respects the account’s configured name order. (refs DAG-154)

## Bug Fixes

The following issues were resolved in this release.

- **Fixed navigation issues on large documents.** The Next button now correctly navigates to the next signature after zooming on documents over 100 pages. (refs PB-123566)
- **Improved country selector display.** A separator line that appeared as a block in certain OS/browser combinations has been removed. (refs PB-123881)
- **Maintains page focus when reordering documents.** Sometimes the current page focus would be lost after reordering documents in the Designer. This no longer happens. (refs PB‑124000)
- **Corrected locale formatting errors in email notifications.** Extra spaces in the language parameter are now automatically trimmed. (refs PB-124047)
- **Ensures fields are not duplicated when pasting.** Duplicate fields are no longer created when pasting fields in the [Designer](/v1/docs/using-the-designer). (refs PB‑124252)
- **Prevents errors when adding recipients.** Fixed an issue in which an error message would sometimes appear when adding a recipient to a transaction. (refs PB‑124602)
- **Increased tooltip font size on mobile devices**. For better visibility and ease of use we have increased the tooltip font size on mobile devices. (refs PB-124992)
- **Updated infrastructure in response to upcoming Salesforce policy changes.** We have updated our backend infrastructure and Salesforce Connector to accommodate Salesforce’s upcoming enforcement of PKCE and Refresh Token Rotation polices changes. (refs PB-124844)

## Known Issues

This section lists issues that have not yet been resolved for the current OneSpan Sign release.

- **Duplicate sender-as-signer cannot sign a second time.** A sender who is a recipient in a counter signing transaction will not see the **Sign** button when it is their turn to counter sign if that sender does not have manager permissions in the account where the transaction is created. Additionally, when viewing the **Transaction Edit** page of that transaction, they will see the recipient information as masked within the **Recipients** section. This issue will be fixed in an upcoming 26.R3 Sandbox deployment. (refs PB-125516)
