First Reported: August 2024
Ultima actualizare la
10 feb. 2026
The Adobe Sign Technical Notifications are ordered below with the oldest update at the top, and rolling forward in time as you scroll down the page.
|
|
Removed from Current list: January 2025 |
|---|
The legacy Accept-Charset header will be removed from all Webhook and Callback notifications with the November 2024 release.
All customers that rely on this header for any reason should refactor their code to account for it's absence.
|
First Reported: September 2024 |
Removed from Current list: January 2025 |
|---|
|
First Reported: November 2024 |
Removed from Current list: January 2025 |
|---|
With the November 2024 release, the editable labels in the Custom Workflow Designer have been limited to 100 characters. This limit is evaluated when the workflow is created or updated.
Preexisting workflows that have labels over 100 characters can still be sent successfully, but if the workflow is updated, the label must be reduced to 100 characters or less before it can be saved. Offending labels are outlined in red for easy discovery.
New workflows will warn about the label limit before they are saved.
Action Required
It is recommended that admins with control over custom workflows open and review each workflow to ensure that they don't have errors on their template.
|
First Reported: November 2024 |
Removed from Current list: February 2025 |
|---|
The new recipient experience contains signing improvements for both desktop and mobile web browsers. This new experience is being rolled out over the first months of 2025 but will be available in the Sandbox environment in the first week of December 2024.
|
First Reported: December 2024 |
Removed from Current list: February 2025 |
|---|
Adobe Acrobat Sign will rotate the Adobe Acrobat Sign SSL Certificate on January 22, 2025.
In addition, a new SSL certificate is being deployed to support the WAF network changes being made in January 2025. This new certificate directly impacts access to the Acrobat Sign service and must be installed before the WAF goes online.
Action Required
- Every customer account that explicitly secures network activity must include the new WAF SSL certificate in its list of stored certificates.
- If you have custom-built integrations with Acrobat Sign using either the SOAP or REST APIs and if any of these integrations have ‘pinned’ the existing public key, no other action is required.
- If you are using Acrobat Sign’s SSL certificates for SSO, or if you’re pinning the certificate itself (or using other methods), you can find the new Acrobat Sign SSL certificates in the Adobe Acrobat Sign System Requirements.
- If your SSO configuration supports multiple public certs/chains, you can add the new certificates now and remove the old public cert/chain from your configuration after the January switch.
- If your SSO does not support multiple public certs/chains, you will need to sync your SSL switch with Acrobat Sign on January 22, 2025.
The new SSL certificates will be active on January 22, 2025.
|
First Reported: September 2024 - Updated February 2025 |
Removed from Current list: March 2025 |
|---|
To improve Adobe Acrobat Sign service security and robustness, we will start to roll out network changes to include a web application firewall (WAF) in February 2025. These changes will route traffic into Acrobat Sign application servers through the WAF service. This routing will be invisible to most customers. Usage will not interfere with access to Acrobat Sign from any Adobe clients or integrations.
Action Required
None.
This change will not affect customer integrations, as the Acrobat Sign API and API domain names will not change. This solution is backward compatible with the published IP ranges.
Customers who have updated their security devices don't need to revert or make any other changes.
The current update schedule is:
- Production Sandbox updates February 24, 2025.
- Production shards: IN1, JP1, AU1, and SG1 will update March 3, 2025.
- Production shards: NA2, NA3, and EU2 will update March 6, 2025.
- Production shards: NA1, NA4, and EU1 will update March 11, 2025.
-
Ingress and Egress Access to Acrobat Sign
Acrobat Sign is no longer retiring the list of server ingress IP addresses as previously announced.
The server ingress and egress IP addresses, as documented on the System Requirements for Acrobat Sign page, will remain viable. -
Why is Acrobat Sign making these Changes?
The use of a WAF improves Acrobat Sign's protection against harmful traffic and helps us better address security, robustness, and compliance requirements.
-
I have a custom integration into Acrobat Sign. Will my application be affected?
No, we don't expect any integrations to be negatively impacted.
-
Are there new IP address lists that can be substituted?
No.
The information on the System Requirements for Acrobat Sign page remains accurate. -
My organization has implemented network filtering using Acrobat Sign's published domain list for traffic from our corporate network. Are we affected?
No.
The network changes described here do not impact Acrobat Sign's domain list, as documented on the System Requirements for Acrobat Sign page. Domain-level filtering is unaffected. -
My organization employs IP address validation for email delivery from Acrobat Sign servers. Are we affected?
No.
The IP ranges for outbound mail relays, as listed on the System Requirements for Acrobat Sign page, are not changing. -
My organization has configured our Acrobat Sign account to restrict access to our own IP addresses. Are we affected?
No.
Acrobat Sign can be configured to validate incoming traffic against customer-chosen IP addresses, as described on the Restrict access to your account using IP address ranges page. Such usage will not be affected by this change. -
My organization has implemented network filtering using Acrobat Sign's published list of ingress IP addresses. Are we affected?
No.
The new WAF configuration is backward compatible with the existing network architecture, so no additional tuning of your security devices should be required.
Notă:Note that this refers to IP-level filtering for the environment hosting your application. Domain-level filtering is not affected.
-
I'm using the Salesforce integration with explicitly configured IP allow-listing. Do I need to do anything?
No.
The WAF installation requires no changes for existing Salesforce installations at this time.
The existing configuration/process, as described in the help documentation, remains the same, and administrators should follow all IP allow-listing steps.
ISV and Embed Partners should contact their Success Manager for any further questions.
|
First Reported: November 2024 - Updated: January 2025 |
Removed from Current list: March 2025 |
|---|
Senders can provide an additional view of agreements for mobile recipients that lists only the field within the agreement available to the recipient.
Senders can arrange the field list as they like, and group fields into logical sections to help the signers move through the field input with a minimum of scrolling.
Recipients have the option to view the mobile-friendly fields list or the original PDF view with the fields placed within the document content.
This feature is scheduled to be released:
- To be deployed on the Sandbox environment on December 11, 2024
- To be deployed on the Production environment on March 4, 2025
|
First Reported: May 2024 |
Removed from Current list: March 2025 |
|---|
The option to use an external drive for uploading files will be limited to OneDrive only in the new Request Signature experience.
It's recommended that customers who use other options for file upload use the vendor-specific application to provide a networked drive that can be accessed through the native file picker on the user's local system.
- Dropbox: https://www.dropbox.com/desktop
- Google Drive: https://support.google.com/drive/answer/10838124
- Box: https://support.box.com/hc/en-us/articles/360043697194-Installing-Box-Sync
- Acrobat/Document Cloud: https://www.adobe.com/acrobat/hub/share-sync-pdfs.html
|
First Reported: May 2024 |
Removed from Current list: April 2025 |
|---|
Action Required
All integrations and applications using the Adobe Acrobat Sign SOAP API must be migrated to the latest REST API V6 before the disablement date to ensure continued function.
Access to the SOAP API will be removed for all embed partners starting March 1, 2025.
To ensure continued function, all embed partners using the Adobe Acrobat Sign SOAP API must migrate to the latest REST API V6 before March 1, 2025.
Please review the REST v6 and migration documentation for reference:
- Adobe Acrobat Sign REST API Version 6 Methods
- Migrating from SOAP
For any queries, please contact your designated Adobe Acrobat Sign PSM.
Notă:
This update only applies to the Commercial version of the Acrobat Sign service. Government Cloud accounts are not impacted.
This update only applies to the Send (Request e-signatures) page. Structured Self-signing workflows are not yet included.
|
First Reported: March 2024 - Updated January 2025 |
Removed from Current list: April 2025 |
|---|
Starting with the April 2025 release, the modern Request Signature environment will become the default experience when creating a new agreement.
- Users will no longer be able to switch between the new and classic environments, as switch links will be disabled.
- Administrators will still have the option to enable the classic experience and restore switch links through the admin menu.
- Customers using the Notarize integration will not be affected by this change.
|
First Reported: March 2024 - Updated April 2025 |
Removed from Current list: April 2025 |
|---|
Notă:
This update only applies to the Commercial version of the Acrobat Sign service. Government Cloud accounts are not impacted.
As of the April 2025 release, the modern Request Signature environment will become the Default experience available when creating a new Send in Bulk template.
- Users will not be able to switch back to the classic environment.
- Administrators will have the option to enable the classic experience and restore switch links through the admin menu.
|
First Reported: February 2025 |
Removed from Current list: April 2025 |
|---|
The Account tab, available to Acrobat Sign account-level administrators, will be renamed Admin.
- This update applies exclusively to the Acrobat Sign Standalone environment (Acrobat Sign Solutions and Acrobat Sign for Government).
- The update will be implemented for the Commercial environment in April 2025 and the Government environment in May 2025.
Note that this change is purely cosmetic—there are no functional modifications, only updates to the tab labels.
Notă:
The Group label for group-level admins will not change.
|
First Reported: March 2025 |
Removed from Current list: April 2025 |
|---|
- Improved User Login Experience - Acrobat Sign has streamlined the login and authentication process through the Adobe Identity Management System (IMS).
- The user's organizational profile is automatically selected during the login process to the ones entitled with the Acrobat Sign service ( Identifying the request as coming from an Acrobat Sign source)
- Users who encounter errors during login will have links in their error messages to contact their Acrobat Sign administrators for assistance.
- All users assigned an active entitlement but have not logged in to the service will be sent up to two email reminders. (This also applies to existing inactive users before the release date )
These improvements simplify login, reduce friction, and improve the overall user experience.
Available environments: Commercial | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Enabled by default; Not configurable
|
First Reported: March 2025 - Updated: April 2025 |
Removed from Current list: June 2025 |
|---|
Starting after the May 2025 release, Acrobat Sign will implement stricter limits on the number of webhooks created in Developer-tier accounts.
These limits have been purposefully chosen to ensure the reliability of the webhooks infrastructure and better aligned for testing workflows.
|
What is changing |
Previous limit |
New Limit |
Description |
|---|---|---|---|
|
Number of active webhooks created per channel |
10 |
1 |
1 webhook is allowed for the channel per webhook subscription event. |
|
Number of active webhooks created for an account |
100 |
2 |
2 account level webhooks are allowed per webhook subscription event. |
|
Number of active webhooks created per group |
100 |
2 |
2 group level webhooks are allowed per group per webhook subscription event. |
|
Number of active webhooks created per agreement resource |
50 |
1 |
1 webhook is allowed per agreement per webhook subscription event. |
|
Number of active webhooks created per user |
100 |
1 |
1 webhook is allowed per user per webhook subscription event. |
Available environments: Commercial | Available tiers of service: Developer | Configuration scope: Enabled by default; Not configurable
|
First Reported: March 2025 |
Removed from Current list: April 2025 |
|---|
Acrobat Sign customers can now subscribe to the Acrobat Sign Webhook service to receive proactive notifications about outages, disruptions, and maintenance events via the Adobe Status Portal.
Manage and add subscriptions here: Adobe Status Subscription Help.
Note that the Adobe Acrobat Sign service is listed under the Document Cloud heading:
|
First Reported: March 2025 |
Removed from Current list: June 2025 |
|---|
In the May 2025 release, we’re optimizing the GET /agreements API to significantly reduce response times—our internal testing shows improvements of up to 10x.
What’s changing
- Smaller page sizes: To support these improvements, we’ve reduced the maximum number of agreements returned per request to 500, but this limit may change in future releases. Each response includes:
- The actual number of agreements returned
- A link to the next page of results (if available)
- Dynamic result count: You can still request a specific number of agreements, but the API will return as many as the service can provide. Each response includes:
What to expect
In some cases, there may be a slight delay between creating an agreement and retrieving it using the GET /agreements API. This delay is typically very short; a follow-up request should return the new agreement.
Available environments: Commercial, Government | Available tiers of service: Acrobat Sign Services, Government | Configuration scope: Enabled by default; Not configurable
|
First Reported: April 2025 |
Removed from Current list: August 2025 |
|---|
All accounts using the Acrobat Sign for Government service will gain access to enable the new Request Signature environment, along with several features recently created that are dependent upon it:
- eWitnessing
- Restricted access to agreements
- Enforce signature type
- Identity check
- CCs per recipient
- The recipient list and recipient properties are editable after authoring
|
First Reported: September 2024 |
Removed from Current list: Feb 2026 |
|---|
Action Required
All customers using the API must update their APIs to utilize the version 6 endpoints as soon as possible to ensure uninterrupted availability.
Versions 1 through 4 of the Acrobat Sign REST API have been deprecated and will be removed from service on December 1, 2025.
Updating APIs can involve considerable effort, so all customers are strongly encouraged to scope and budget their update as soon as possible so that support can be fully engaged to resolve any questions or problems that arise before the December 2025 cutoff date.
While REST API v1-4 are deprecated, they will continue to function, and your applications will continue to work until December 1, 2025, when the REST API v1-4 will be removed.
After December 1, 2025, applications built on the REST API v1-4 will cease functioning.
|
First Reported: April 2025 |
Removed from Current list: Feb 2026 |
|---|
All accounts using the Acrobat Sign for Government service will gain access to enable the new Request Signature environment, along with several features recently created that are dependent upon it:
- eWitnessing
- Restricted access to agreements
- Enforce signature type
- Identity check
- CCs per recipient
- The recipient list and recipient properties are editable after authoring
|
First Reported: September 2024 - Updated April 2025 |
Removed from Current list: Feb 2026 |
|---|
The Webhook 2.0 infrastructure has been rolled out to all customers, and with that completed, signer notifications have been deprecated. As a result, the webhookNotificationApplicableUsers parameter of the webhook payload no longer provides any useful data and will be removed from all webhook payloads.
The Sandbox environment will be updated in the June release.
The Production environments will be updated in the July 2025 release.
The sending userID and email can be found using the initiatingUserId and initiatingUserEmail parameters in the notification payload.
|
First Reported: August 2025 - Updated October, 2025 |
Removed from Current list: Feb 2026 |
|---|
To help maintain system stability and improve performance, Acrobat Sign will introduce a polling threshold in the November 4, 2025 release (version 16.2.1). This change limits how frequently client applications can poll specific API endpoints.
- Customers have two months following the 16.2.1 release to implement the recommended polling changes in their code. During this time window, the system will only LOG the polling interval threshold events.
- After December 2025, the polling protection policies will be switched to ENFORCE, and the errors will start triggering for users.
High-frequency polling creates an unnecessary load on backend systems, resulting in degraded performance and slower response times. API developers are encouraged to switch to webhooks for real-time updates.
What’s Changing
This polling policy applies to all GET API endpoints.
Examples of Affected Endpoints
Status Retrieval:
- GET /agreements/{agreementId) – Retrieves the current status of an agreement.
- GET /agreements/{agreementId)/documents/{documentId) – Retrieves the file stream of a document within an agreement.
Listing:
- GET /agreements – Retrieves agreements for the user.
- GET /agreements/{agreementId)/events – Retrieves event information for an agreement.
A limit will be applied to how often the effective user can make the same API call to the Acrobat Sign service. An error is returned if the same call is made within the minimum polling interval by the same effective user.
Polling Policy Details
- Minimum Object Polling Interval (MOPI): The default MOPI varies depending on the tier of service and application types:
- Acrobat Sign partner applications: The MOPI for a partner app is determined by the tier of the user’s account.
- GLOBAL/ENTERPRISE tier: 3 calls per one‑minute interval
- All other tiers: 1 unique call per ten‑minute interval
- Customer applications under Global/Enterprise accounts: Three identical calls per one-minute interval.
- Customer applications under Developer accounts: One unique call per 10-minute interval.
- Acrobat Sign partner applications: The MOPI for a partner app is determined by the tier of the user’s account.
- Duplicate Requests Within MOPI: If the same effective user makes identical GET requests (same path and headers) more than their tier allows within the MOPI, the system will return:
- 304 Not Modified status code to HTTP conditional requests using an ETag.
- 429 Too Many Requests status code with a retry-after for other requests.
- ETag Handling: This policy applies when ETag values are provided in the If-None-Match header for endpoints that already support 304 Not Modified.
Action Required
Webhooks: If your application requires near real-time updates, use webhooks instead of polling. Webhooks provide a more efficient and scalable way to receive timely updates.
If webhooks cannot be implemented, applications should implement client-side caching mechanisms to store and reuse API responses. When a 304 Not Modified response is received, the cached data should be used instead of making another API call.
Customers have two months following the 16.2.1 release to implement the recommended polling changes in their code. During this time window, the system will LOG the polling interval threshold events.
After December 2025, the polling protection policies will be switched to ENFORCE the errors will start triggering for users.
Please contact your CSM if you need assistance or have any questions.
The sandbox environment will enable the polling policy to LOG errors on September 17, 2025, and set to ENFORCE on September 25, 2025.
|
First Reported: August 2025 |
Removed from Current list: Feb 2026 |
|---|
To support FedRAMP CSP requirements, we are enabling the IPv6 protocol on our Acrobat Sign for Government environment:
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
First Reported: September 2025 |
Removed from Current list: Feb 2026 |
|---|
Language settings validation has been tightened when creating an agreement via API. If an agreement’s locale isn't permitted by the account’s policies, the API rejects the request with a clear error. This reduces unintended language mismatches and keeps recipient experiences aligned with approved settings.
Who is affected
- Accounts that set the agreement locale in API requests.
- Accounts that restrict available locales or disallow locale changes during send.
What changed
When the DISPLAY_LOCALE_INFO_DURING_SEND setting is enabled (GLOBAL tier), the API enforces:
- The agreement’s locale must be included in the user’s AVAILABLE_LOCALES.
- If ALLOW_LOCALE_SELECTION_DURING_SEND is false, the agreement’s locale must match the user’s AGREEMENT_LOCALE.
Violations cause POST /agreements to fail with: “Locale is either invalid or missing.”
Common error and how to fix it
Error: “Locale is either invalid or missing.”
- Check the locale used in the API request (for example, en_US).
- Confirm that locale appears in AVAILABLE_LOCALES for the calling user.
- If ALLOW_LOCALE_SELECTION_DURING_SEND is false, ensure the request’s locale matches AGREEMENT_LOCALE.
- If flexibility across regions is required, enable send-time locale selection (see Action required).
Backward compatibility
- Prior to this change, some requests with mismatched locales could succeed. Such requests now fail with a clear error when validations do not pass.
- No API schema changes; validation behavior changes only when DISPLAY_LOCALE_INFO_DURING_SEND is enabled.
Action required
Admins and API integrators should do one of the following:
- Align the locale in API requests with AVAILABLE_LOCALES, and—if ALLOW_LOCALE_SELECTION_DURING_SEND is false—match AGREEMENT_LOCALE exactly
- or -
- Allow send-time locale selection by setting:
- ALLOW_LOCALE_SELECTION_DURING_SEND = true
- CAN_CHANGE_UI_LOCALE = true
|
First Reported: December 2025 |
Removed from Current list: Feb 2026 |
|---|
Adobe Acrobat Sign will rotate the Adobe Acrobat Sign SSL Certificate on January 7, 2026.
Action Required
- If you have custom-built integrations with Acrobat Sign using the REST APIs and if any of these integrations have "pinned" the existing public key, no other action is required.
- If you are using Acrobat Sign’s SSL certificates for SSO, or if you’re pinning the certificate itself (or using other methods), you can find the new Acrobat Sign SSL certificates in the Adobe Acrobat Sign System Requirements.
- If your SSO configuration supports multiple public certs/chains, you can add the new certificates now and remove the old public cert/chain from your configuration after the January switch.
- If your SSO does not support multiple public certs/chains, you'll need to sync your SSL switch with Acrobat Sign on January 7, 2026.
The new SSL certificates will be active on January 7, 2026.
|
First Reported: September 2024 - Updated April 2025 |
Current |
|---|
The Webhook 2.0 infrastructure has been rolled out to all customers, and with that completed, signer notifications have been deprecated. As a result, the webhookNotificationApplicableUsers parameter of the webhook payload no longer provides any useful data and will be removed from all webhook payloads.
The Sandbox environment will be updated in the June release.
The Production environments will be updated in the July 2025 release.
The sending userID and email can be found using the initiatingUserId and initiatingUserEmail parameters in the notification payload.