Last updated on
5 Mar 2026
Note
This document highlights the new features, experience changes, and resolved issues in the customer-facing application for the most recent release.
Developer-centric updates to the API and Webhooks are documented in the Acrobat Sign developer guide.
Not all features/changes are guaranteed to be enabled on the date of the release. Always refer to the US English version of the page as the most current and accurate version.
Adobe Acrobat Sign release v17.0.1
Production deployment: March 17, 2026
GovCloud deployment: March 19, 2026
Improved Functionality
- Create a copy – Expanded access points, faster reuse of agreements.
Create a copy is now available directly from the In progress and Waiting for you filters on the Manage page, as well as from the post-send confirmation page. These additional entry points make it easier to reuse agreements at more points in the sending lifecycle, reducing the need to restart from scratch.
Note: With this release, the administrative controls to disable this feature will be removed from the admin menu, establishing Create a copy as a standard capability available to all eligible users.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Account and Group; Enabled by default.
REST API/Webhook Updates
API and webhook updates for this release can be found in the Acrobat Sign API documentation.
- OEM 2.0 personalized email display – Clearer sender and recipient identity across embedded experiences, and correct email delivery.
For OEM 2.0 embedded workflows, Acrobat Sign now displays a user’s personalized email address instead of the partner-registered email across key UI surfaces and notifications. Agreements, queues such as “Waiting for you,” and “Review and Sign” emails consistently reflect the personalized identity while preserving the registered email internally for authentication and entitlements. This improves clarity for senders and signers and prevents emails from being sent to non-deliverable registered addresses.
Available environments: Sandbox, Commercial | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API
- Webhook notification for SMS delivery failures – Real-time visibility into failed SMS sends, automated remediation, and parity with email bounces.
Acrobat Sign now emits a new webhook event, AGREEMENT_PHONE_BOUNCED, when an agreement sent via SMS cannot be delivered due to issues such as invalid phone numbers, carrier rejection, or blocked lines. This enables customers to detect SMS delivery failures in near real time and automatically trigger follow-up actions like correcting phone numbers, retrying delivery, or opening support cases, eliminating blind spots and reducing delays in mobile-first signing workflows.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API
- Webhook payloads – Added conditional participant extendedStatus field for dynamic participation updates, improving participant state visibility.
Webhook notifications now include an extendedStatus field in each participant (memberInfos[]) object when the sender modifies an in-flight agreement using dynamic participation. This field provides additional participant lifecycle detail while leaving the existing status field unchanged for backward compatibility.
{
"participantSets": [
{
"id": "",
"memberInfos": [
{
"company": "TestCo",
"email": "signer2@someDomain.dom",
"id": "CBJCHBCAABAAJiZV9cH",
"name": "Signer Two",
"status": "ACTIVE",
"extendedStatus": "REMOVED"
}
],
"order": ,
"role": "",
"status": ""
}
]
}
status values (unchanged): ACTIVE, REPLACED.
extendedStatus values: ACTIVE, REPLACED, REMOVED, COMPLETED.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API
Resolved Issues
| Issue | Description |
|---|---|
| 4543515 | Summary: A webhook email bounce event may be incorrectly generated for a valid signer after the signer successfully signs and the agreement advances to the next step. This can occur when a delegatee in the same signing group has an invalid email address and the sender replaces the original delegator. In these cases, the system may incorrectly attribute the “signed on behalf of…” bounce event to the valid signer instead of the participant whose email actually bounces. |
| Fix: The event attribution logic was corrected so email bounce events are associated only with the participant whose email actually bounces. A bounce event is no longer generated for a valid signer who has already completed signing, and webhook notifications now reflect the correct participant and email address. | |
| 4544548 | Summary: Integration Keys created through the Web UI may expire after 10 years, even though the creation page states that the key provides “permanent access.” When a key reaches its 10-year lifetime, API calls begin returning an expired token error, which may break existing integrations unexpectedly. |
| Fix: The user interface messaging was updated to remove the “permanent access” wording and clearly display the expiration date for Integration Keys. The updated text now states that the key retains access until the expiration date or until it is manually revoked, providing transparency about the 10-year default lifetime. | |
| 4546301 | Summary: Webhook event delivery may be delayed by up to multiple hours for agreements with very large documents, even when agreement creation completes and early processing steps appear to finish within minutes. During the delay window, the webhook delivery service may repeatedly receive DOCUMENT_NOT_AVAILABLE responses when attempting to retrieve agreement documents, and the webhook event may not be delivered until the service stops retrying or the documents become available. |
| Fix: Document availability handling was corrected so large agreements reliably transition to a state where documents are retrievable without extended DOCUMENT_NOT_AVAILABLE responses. As a result, webhook events are delivered without multi-hour delays caused by document retrieval retries against unavailable documents. | |
| 4547823 | Summary: A recipient's private message may not display for some signers when an agreement is created in the Authoring state through the API and then edited from the Manage experience. In this scenario, the UI may show the Private Message value as “None” or blank even though the agreement data includes the correct private message value. This behavior appears in shared-account scenarios where a user switches into another user’s account to edit the draft, and it may affect only specific recipients while others display correctly. |
| Fix: A check was added to retrieve the active share context and return the private message for authorized shared users. As a result, the Private Message value now displays correctly when viewing or sending an API-created draft from the Authoring flow. | |
| 4548274 | Summary: The Modified Date for library templates may not update after a template is edited and saved in the new template experience. Users may see newly added or updated fields on the template, but the Modified Date remains unchanged in the Manage UI and in administrative views, which makes it appear that the template was not recently modified. This occurs because the new experience updates form fields through a path that does not also update the template’s modified timestamp. |
| Fix: The modified date update behavior was aligned across the new template experience and the related API operations. The code path that saves template field changes now also updates the template’s Modified Date so it reflects the actual time of the most recent change. | |
| 4548564 | Summary: Signatures and form fields may appear invisible in the signed PDF when they are placed over pre-existing stamp annotations in the source document. In affected templates, the stamp annotations overlap or obscure the interactive fields during processing, causing completed signatures and other fields to be hidden in the final signed document. |
| Fix: Stamp annotation handling was updated to safely process and flatten pre-existing stamp annotations so they no longer obscure form fields or signatures. Fields placed over stamped areas now remain visible throughout signing and in the fully executed PDF. | |
| 4549103 | Summary: An email bounce event may be logged again for a previously incorrect recipient after the sender replaces that recipient with a valid email address. In some cases, the audit trail may show a second bounce event for the old email, and the agreement status may reflect “email bounced” even though the new recipient successfully receives, views, or signs the agreement. This behavior can make it appear that the agreement is still targeting both the old and new email addresses. |
| Fix: The replace signer workflow was updated to prevent sending additional notification emails to a replaced recipient whose email has already bounced. The system now checks for prior bounce history before sending replacement-related notifications, ensuring that no new bounce events are generated for the old email address after replacement. | |
| 4549306 | Summary: Users whose email addresses contain certain special characters (for example, an apostrophe) may be unable to log in from the generic adobesign.com or echosign.com public login pages. After entering the email address and clicking into the password field, the page may reload and clear the email field instead of redirecting the user to the correct shard or SSO login page. This prevents affected users from completing authentication and blocks integrations that rely on the public login endpoint. |
| Fix: The login shard resolution logic was corrected to properly handle and decode email addresses containing special characters before constructing the inter-shard redirect URL. Users with affected email formats are now correctly redirected to their designated shard and SSO login page without the email field being cleared. | |
| 4549331 | Summary: Signatures and other form fields may appear missing or invisible in the signed PDF when certain document processing features are enabled and the source PDF contains invalid page box coordinates (for example, incorrect CropBox or MediaBox values). In this scenario, fields that rely on page coordinates may render outside the visible page area, making completed signatures appear missing even though signing completes successfully. |
| Fix: PDF page box handling was corrected to safely normalize invalid CropBox and MediaBox values during document processing. As a result, signature and form field placement now aligns to the visible page area, and signed PDFs display signatures as expected. | |
| 4550367 | Summary: Creating a web form may fail with a generic “Server error” after selecting Preview and Add Fields when the sender’s group default signer authentication is set to Phone and the account does not have available phone authentication quota, even if the web form signer authentication is set to a non-phone method (for example, Adobe Sign). As a result, all users in the affected account may be blocked from creating web forms across all documents. |
| Fix: Web form creation now evaluates quota only for the authentication method actually configured for the web form signer, and it no longer applies phone authentication quota checks based solely on the group default authentication setting. This prevents false quota exhaustion errors and allows web forms to be created normally. | |
| 4551011 | Summary: When a sender uploads certain scanned PDFs, adds signature fields, and sends the agreement, the signed PDF may display no visible signatures after signing completes. This behavior may occur when the uploaded PDF contains invalid page boundary metadata (MediaBox and CropBox coordinates appear reversed), which can cause signature and other field appearance layers to render outside the visible page area. |
| Fix: PDF page boundary handling is updated to correctly process PDFs with invalid or reversed MediaBox and CropBox coordinate values, so signature and form field appearance content renders within the visible page area and remains visible in the final signed PDF. | |
| 4551427 | Summary: Some recipients who already have active, correctly provisioned accounts receive agreements as “pseudo user” recipients instead, so the agreement does not appear in their normal Manage view. This happens when recipient email addresses include leading or trailing spaces, which prevents the system from matching the email to the existing user and causes a pseudo-user record to be created. |
| Fix: Email parsing and user lookup were updated to normalize recipient email addresses (trim leading and trailing whitespace) before matching them to existing users. As a result, agreements addressed to existing users resolve to the registered account instead of creating a pseudo-user recipient, even if the email was entered with spaces (in API payloads and workflow recipient lists). | |
| 4553198 | Summary: When an agreement includes at least one recipient configured for SMS delivery and at least one recipient configured for email-only delivery, canceling the agreement through the API does not send an SMS cancellation notification to the SMS recipient. The agreement is successfully cancelled, and email notifications are delivered, but SMS recipients do not receive a cancellation message. |
| Fix: The cancellation workflow was corrected to ensure that SMS cancellation notifications are sent to all recipients configured for SMS delivery when an agreement is cancelled, regardless of other recipients’ delivery methods. | |
| 4554463 | Summary: When agreements include cloned radio buttons that share the same field name across combined documents, only one instance of the selected option remains selected in the final signed PDF. Although the fields appear visually as checkboxes, they are implemented as radio buttons. After signing, the selected value does not consistently propagate across all cloned instances, causing incorrect or incomplete mapping of the expected selection. |
| Fix: The form field handling logic was corrected so that cloned radio buttons store and propagate the selected export value rather than an internal index value. This ensures that all cloned instances of the same radio button field reflect the correct selection in the signed PDF. | |
| 4554593 | Summary: Some partner integrations that use the legacy OAuth endpoints to refresh access tokens started failing with HTTP 401 errors. The service rejected token refresh requests with an error indicating that the application is not allowed to use the legacy OAuth endpoints and must use the OAuth v2 endpoints instead. This blocked customers from authenticating Acrobat Sign through partner applications, even for integrations that were previously working. |
| Fix: The authentication service was corrected so partner applications that are configured to use the legacy OAuth flow can successfully refresh tokens again, instead of being incorrectly forced onto the OAuth v2 endpoints. | |
| 4554614 | Summary: When a signer uses the modern eSign experience on an agreement that requires signer authentication and is configured to require acceptance of terms of use before signing, clicking Click to Sign triggers a 5-second redirect to the classic signing experience. The redirect message warns that signatures and initials entered in modern signing will be cleared, forcing the signer to re-enter them and effectively sign twice. |
| Fix: The signing token refresh flow was corrected so that when the signer accepts the terms of use before signing, the reissued signing token retains the signer authentication details. This prevents the final signing step from failing authentication and eliminates the forced fallback from modern signing to the classic experience. | |
| 4555656 | Summary: Under specific timing conditions, an agreement state transition may appear to succeed but does not actually change the agreement state. When a webhook notification is received before backend processing completes, subsequent API calls can use stale agreement status data. In this window, certain state transition methods return HTTP 200 OK even though the agreement is not in a valid state for the requested transition. As a result, automation workflows may assume the transition succeeded while the agreement remains in the original state. |
| Fix: Agreement state transition logic was updated to enforce strict validation before applying a transition. If the agreement is not in a valid state, the API now returns a clear error response instead of silently returning success. This ensures invalid transitions are explicitly rejected, enables calling systems to retry appropriately, and prevents agreements from remaining in an unintended state without visibility. |
