Adobe Acrobat Sign Release Notes - 2021

Adobe Sign Release Notes: 2021  

Adobe Sign: March 2021  

Improved Functionality

Multi-signer web forms

Accounts that use Web Forms now have the ability to allow for multiple external recipients in the signature process.

Additional recipients are defined by the initial signer:

Multi recipient web form

Use Library Templates to create Web Forms

Authors can now use existing Library Templates to create new Web Forms. The file is imported with all fields intact:

Webform from Template

"Liquid Mode" in Adobe Sign for Mobile Viewing

Liquid Mode is an optional feature for generating a responsive view so you can improve the display of your documents based on the signer's device type.

The signed document is stored in the standard "PDF" version while the recipients can see the Liquid Mode on mobile phones and can toggle to view the original document.

You can now upload your HTML document and generate a Liquid Mode view for mobile phones.

More details on the Liquid Mode option can be found here >

Example Liquid Mode

Lock the Name value for known users when signing via Image or Drawn signature methods

There are situations where the ability to change the name of the recipient during the signing ceremony is undesirable. Adobe Sign has provided flexibility in this regard in deference to the name preference of the Signer.  In more compliant environments this flexibility is unacceptable so there is a new control to lock the names of the recipients to the agreement.

Admins now have the ability to prevent recipients with known Name values from changing those values when they apply a Drawn or Image signature.

Situations where the name value is known:

  • When sending to a recipient with an Adobe Sign ID
  • When sending the name through the API
  • When the Signer Info fields are completed during form filling
  • When the name is locked during the completion of a KBA or Government ID authentication

More details on this feature can be found here >

Allow recipients to edit their name


Improvements to Knowledge-based Authentication

Controls have been added to the KBA method of identity authenticaiton that can require the sender to provide a Name for the recipient and that Name value is locked in place through the signature process.

KBA lock name value.png

Options for enhanced email security

Two new options are available to improve email security. Both settings are enabled by default:

Email security options

Email options - pair.png

v6 REST API Updates


By default, every v6 REST API request now has the below standard headers:

Standard Headers.png


All /agreements endpoints that have an agreement id path now return a 404 AGREEMENT_DESTROYED error code if the agreement has been deleted via GDPR tools.  


PUT /libraryDocuments/{libraryDocumentId} - Expanded to include the new field ownerId


Only the v6 REST API is impacted.

Any v6 REST API call that does not include these headers will explicitly document that absence.



Get Library documents

New fields in LibraryDocumentInfo object:


Fields with updated behaviour:



  • POST /widgets - Using a libraryDocumentId to create a web form is now supported with a valid id

Added status code:

Post Widgets

  • PUT /widgets - Using a libraryDocumentId to create a web form is now supported with a valid id

Added status code:

Put Widgets

Put widgetID entity

Added status code:

Put widgetID entity

Experience Changes

New fields in WidgetInfo object:

Get WidgetID

Fields with updated behaviour:

Get WidgetID



Get megasignID Formfields


Get megasignID Formfields parameters

Response object:

Get megasignID Formfields response

Put megasignID Formfields


Put megasignID Formfields

Response object:

Put megasignID Formfields


  • POST /megaSigns AUTHORING has been added as a state value to support authoring a Mega Sign template

Changed Parameter:

Post Megasigns.png

  • PUT /megaSigns/{megaSignId}/state - AUTHORING has been added as a state value to support authoring a Mega Sign template. As a result, megaSignCancellationInfo is no longer a required field
PUT MegasignID State.png

The modern Home and Manage page has been enabled for all remaining accounts

All accounts have had their control set updated to enable the modern Home and Manage pages for their users.

The controls in the admin menu remain available for accounts that must revert to the classic experience:

v4 page controls

Adobe Sign service level and account ID exposed in Admin menu

Admins can now find their Account ID on the Global Settings page:


The Group ID can be found on the Group Settings page:


Explicit HIPAA configuration

There's a new page available that clearly shows when the account is enabled to manage agreements subject to HIPAA requirements.  

  • This control is only exposed at the account level. Group-level admins do not have access
  • This control is view only, to clearly indicate when the account is configured
  • Contact your success manager or support to enable HIPAA configuration

More information on HIPAA settings can be found here >

HIPAA setting

The "Call to action" button has changed for customers using the Outlook Desktop application on Windows systems

Recipients that use an Outlook Desktop email client will see a change in the "call to action" button on Adobe Sign emails.

The new experience removes the blue HTML button, and instead supplies a clickable text link:



This change only impacts Outlook Desktop apps on Windows systems. Other email clients and operating systems continue to receive the template with the blue button.

Delegation of agreements with digital signatures

The ability to delegate an agreement with digital signatures affixed has been improved to allow delegation from the original email notification to the recipient, through automatic delegation when configured by a user, and through the Replace Current Signer action on the Manage page.

Updated interface for the Payments integration

The Payments interface has been updated to have the authenticating controls better exposed, creating an easier configuration process.

Payment integration

The maximum value for Data Governance has been increased to 5475 days (15 years)

Customers that use data governance rules to automatically delete agreements from the Adobe Sign system can now set that deletion date to a maximum of 15 years (up from ten).

The field level text label for validating the US Social Security Number has been updated:

The field level text label for validating the US Social Security Number has been updated to clarify the SSN is US predicated:

US SSN validation

Reminder: Social Authentication has been removed

As announced in November, the authentication method using social identity has been removed from the list of authentication methods in the Admin menu.

End of Service for SocialID.png

Reminder: Personal Twitter integration has been removed

As announced in December, the Users' ability to make personal authenticated connections to Twitter has been removed.

End of Service for Personal Twitter

Inactive users will receive an email notification when included in an agreement

Users that are set to an Inactive status now receive an email notification instructing the recipient to delegate the agreement to another user.

Resolved Issues

Resolved Issues.png

Adobe Sign: May 2021  

Improved Functionality

Transfer the ownership of library templates and web forms to a different user

Changing the owner of an asset can now be done by any administrator in the account that has access to the asset.

The administrator can assign the asset ownership to any user under their authority.

  • Account admins have access to all shared assets and all users. Therefore, account-level admins can reassign the ownership of any library template or web form to any other user in their account
  • If the asset is configured to only be available to one user (the owner), it is not shared and therefore unavailable to reassign to a new owner
  • Group administrators can only access library templates and web forms within the groups where they have administrator authority
  • Group administrators can only reassign an asset to a user whose primary group falls under their administrative authority


The endpoints described below are only available in the v6 REST API.


Extended to support update of library document owner.



Put LibDocID

Additional Error Status Codes:

Put LibDocID

Extended to support update of widget owner.


Put widgetID

Additional Error Status Codes:

Put widgetID

New fields in LibraryDocument object:


New fields in LibraryDocumentInfo object:

Get LibDocID1211

Fields with updated behavior:

Get LibDocID1211

New fields in WidgetInfo object:

GEt WidgetID 1211

Fields with updated behavior:

GEt WidgetID 1211

Experience Changes

The default v6 REST GET /workflows{workflowId} return value has changed

The v6 REST GET /workflows{workflowId} API call has been updated to return the current version of the WorkflowID (vs. the original version ID, which was the returned value prior to the May release)

This update aligns the default API experience with the Webhook experience, providing the same WorkflowID, which should improve the development and management of applications.

If, for any reason, your account requires the API to return the original ID (as it did prior to the May release), contact support to request that your account return the base version IDs for workflows

Resolved Issues

12-1-1 Resolved issues.png

Adobe Sign: June 2021  

Users in Multiple Groups (UMG)

Administrators in multiple group accounts can now grant Users within their account access to multiple Groups, opening the option to utilize groups as a form of workflow template, enforcing specific sending and signing controls for the library templates available to the group.

Navigate to the Admin UI Options

Existing enterprise and business accounts that would like to upgrade can review the upgrade process here >

A summary of the impactful differences can be found here >

Introducing Liquid Mode in Sign

Enable Liquid Mode view for mobile phones for HTML sent via Send Page or sendAgreement API. The option to enable Liquid Mode in Sign for HTML is now available in the Admin menu list at both the account and group level.

Full details on Liquid Mode documents can be found here >

Liquid Mode in the Admin UI


Liquid Mode is currently available only on the NA1, NA2, and NA4 environments.

Identify your environment here >

Seamless web form updates

Web forms in Draft status can be edited to alter:

  • the Web Form Name
  • the email address of the counter-signer(s)
  • the email address of the CC'd parties
  • the attached files to be edited
  • the fields on the web form (previously available)

Updating an Active web form allows for editing the form elements without changing the original URL, allowing for a frictionless process if you need to update the content of a web form that has already been embedded or sent to your audience. Elements that can be edited are:

  • the files (documents) and applied fields for the recipients
  • counter-signers (from the Manage page)
  • CC'd parties (from the Manage page)
Edit an existing web form


To enable seamless web form functionality, you must enable the Allow additional participants option in the Global Settings menu:

Participation Stamp: Control Title and Company Display

Controls have been added to allow or suppress the recipient Title and Company (derived from the user profile) on the participant stamp field.

Further details can be found on the Field Types page >

Participation stamp

Improved search options: Prefix and Phrase matches

Advanced search options have been introduced to allow for more specific search patterns that will help reduce the returned agreement list.

Further details on how Searching works in Adobe Sign can be found here >

OAuth 2.0 is the new default

A new (improved) version of the OAuth endpoint has been added to avoid usage mistakes. With this version:

  • api_access_point / web_access_point returns only in the Access Token Request (in the body)
  • Adobe Sign doesn’t accept the secret as a query parameter
  • Client secret rotation is supported

The OAuth v1 endpoint will continue to work for existing connections over the next several months to ensure continued access.

The deprecation of OAuth v1 will be announced on the Technical Notifications page once scheduled.


Client Secret Rotation

Application Client Secrets can be rotated by any admin with access to the application ID in the Adobe Sign UI:

Client Secret rotation

Experience Changes

Mega Sign rebrand: Send in Bulk

The name for the Mega Sign feature is changing to Send in Bulk. This is a name change only and does not include any changes in feature behavior.


Group Administrators can only see the API applications that fall under their admin authority

The visibility of applications attached to the account is now constrained only to show the applications that fall under the administrative scope of the user. Only Group admins will see the behavior change:

  • Users see the applications they own
  • Group admins see the apps under the group(s) they have admin authority over
  • Account admins see all applications in the account

Email to the sender when an agreement is complete has been updated

The final email notification for an agreement sent to the sender has been updated to provide a comprehensive list of all parties notified about the completed agreement.

Only the original sender will get this email template.

Expanded email tempalte for the originator of the agreement

New TSP services

New Trust Service Providers from the Cloud Signature Consortium have been integrated to support digital signatures: DigiCert (Switzerland) – Entrust (Global) – VIDA (Indonesia) and Worldline (France).

 Updated v6 REST API Result for  GET /agreements/{agreementId}/signingUrls

Prior to the June release, when calling GET /agreements/{agreementId}/signingUrls, the API would return a 404 immediately after the agreement was created.

For a short time after the 404 error cleared, the response would return a non-404 response, but would only include the sender's signingURLs. (While the signer's participation was still being defined.)

After the June 2021 launch, a 404: AGREEMENT_NOT_EXPOSED code will be returned until the full list of signing URLs is completed, at which time a 200 code is delivered.

Customers that do not want to continue to try the API call until the 200 response is returned are encouraged to use Webhooks, and respond to the AGREEMENT_CREATED event.


Sign Search V6 API for Adobe Sign 

New search-related APIs are being exposed for customer use. The Search API supports listing, searching, filtering, and sorting a user's list of agreements that they have participated in.

Review the Search API here >

Resolved Issues

Adobe Sign: August 2021  

Experience Change

  • Aadhaar International Support – Customers from all Adobe Sign instances can now use the optional Aadhaar service as a digital signature provider. Previously it was only available to accounts on the IN1 instance. The Aadhaar add-on can be purchased at an additional cost per signature transaction.
  • REST v6 Update: POST /users - The REST v6 POST /users API call has been updated to create the user in the account's Default group if the optional primaryGroupId parameter is not defined.  Only the v6 of the REST API is impacted by this change.

Resolved Issues

Issue key



Fixed an issue in the Workflow Designer that would prevent a customer-defined URL in the instructions not to work.


Corrected an issue in the Report CSV file where the To and Recipient Name fields could be left empty when the same recipient email is used more than once in the agreement.


The Adobe Sign templates have been filtered out of the sandbox options.


Corrected an issue where Group Admins could not update users in a group by CSV upload.


Fixed an issue where the GET /groups/ID/users API call would fail if the user was on a different Adobe Sign instance.


Corrected an issue where SAML users created via bulk upload would be in a Created state (instead of Active).


Corrected an issue where group admins could not reassign ownership of Web Forms if other users in their group created them.


Fixed an issue with activating new users when a second activation email was sent to the new user and that second email link was used.


Corrected an issue where the option to Decline the Agreement was not visible when Signing on Behalf of another user.


Fixed an issue where account administrators could not reset passwords when SAML mode was set to Mandatory.


Corrected an issue where Government ID images would not successfully process.


Corrected an issue where Government ID would produce an error indicating the four corners of the document could not be found.


Corrected an issue where Sign on Behalf Of was visible in accounts where the option was not enabled.


Fixed an issue where the email address for 'actingUserEmail' in a GET /agreements/id call would return a system-generated email after the agreement was fully signed.


Corrected an issue where a recipient name would be imported into the Participant 1 label when Knowledge-based Authentication was used for the first signer.


Corrected an issue where automatic notification emails for failing webhooks would be sent to the webhook creator despite being configured not to notify the creator.


Corrected an issue where authentication of OAuth in Power Automate would redirect the user to the home page.


Fixed an issue where admins could not update the Can Send property for users when updating via CSV upload.


Fixed an issue where some customers using the iPad would see the web page instead of the page optimized for mobile devices.


Fixed a display issue with names that contain an apostrophe displaying the HTML code for the apostrophe.


Corrected an issue where users would get an error when archiving an account via the email link.


Fixed an issue where users created via REST v5 and v6 POST /users were not created in the default group.


Fixed an issue where the Signer Identity Report could not be downloaded from the Manage page due to the button being inactive.

Adobe Sign: September 2021  

Improved Functionality

  • Sandbox - Enterprise tier customers have the option to purchase access to a Sandbox environment to test templates, customer workflows, API applications, and more. These objects can be moved from production to the sandbox for updates in a safe environment, then moved back to production once the updates are verified and ready for deployment.
Sandbox - Template view

  • ECDSA Digital Signature Support - Adobe Sign now supports more secure and efficient digital signatures based on the ECDSA format, which uses elliptic curve cryptography as defined in the ANS X9.62-2005 standard.
    NIST curves with SHA-2 hash functions, as defined by FIPS standards, are now supported, giving our Trust Service Providers (TSP) partners from the Cloud Signature Consortium the option to provide signers with faster and safer elliptic curve credentials, including those meeting the recommended requirements for US Federal and Singapore Government use.
  • Liquid Mode Updated -The Liquid Mode signing experience has been extended beyond agreements to include web forms. Liquid Mode forms can dramatically improve the signer's experience by reducing the need to pinch and zoom to view the form content while improving the focus on fields that need to be filled.
Additionally, Liquid Mode is no longer restricted to North American shards. All enterprise and business accounts now have access regardless of location.

Details on Liquid Mode can be found here >

  • New TSPs - Cleverbase (Netherlands), PrimeSign (Austria), Sectigo (Global), and TrustPro (Ireland) are the new Trust Service Providers from the Cloud Signature Consortium providing certificates to apply secure digital signatures that meet the highest standards and compliance requirements.
  • Customize the To and CC fields in email headers to recipients - Customers that are concerned about leaking email addresses via the email headers to recipients can opt to hide the email address values in the To and CC fields.
    • This option is available to enterprise and business tier accounts and can be configured at the account and group levels.
    • The feature controls can be accessed by navigating to Account Settings > Email Settings > Customize To and CC fields.
Customize the To and CC fields in email headers to recipients

Experience Changes

  • Adobe Terms of Use Acceptance on eSign pages - To comply with Adobe Legal requirements, Adobe Sign is updating the terms of use (ToU) acceptance behavior on the eSign page. Under the new experience, all "unknown" recipients must accept the Adobe Sign ToU and Privacy Policy (by clicking the Continue button) before interacting with the agreement. This acceptance is distinct from any custom ToU that the customer account may have configured, which will continue to resolve per the account TOU/CD acceptance configuration.
  • An "unknown" recipient is any email address that is not a registered, active user email in a trusted account.
  • "Known" users have accepted the Adobe Sign ToU as part of the registration process when they verified their user account, so they are not prompted to accept again.

Below is an example of the Implicit consent flow for an agreement with a custom ToU configured by the customer:

  1. Accept the Adobe Sign ToU by selecting the Continue button (after opening the agreement).
  2. Fill in the agreement fields as required.
  3. Accept the Customer Disclosure and custom ToU by selecting the  Click to Sign button.
Gated access to sign

  • Locking name values extended to typed signatures - The March release introduced a setting to enable/disable a recipient's ability to edit their name value when signing, provided the name was supplied or known (via API or user profile).  Typed signatures were excluded from this feature resulting in the ability for some signers to change their name value during the signature process.  The September release updates this feature to honor the name locking setting for all signature types – including typed signatures. 
  • Customers who have enabled Typing their name and initials and disabled Signers can change their name or initials will see a behavior change – the name value is no longer editable during the signature process for typed signatures.
  • Customers that want to allow editing the name-value during the signature process should enable the Signers can change their name or initials setting (in the Signature Preferences menu).
Allow recipients to edit their name

  • Inactive users can sign agreements - Adobe Sign is now treating Inactive users as if they are unknown to the system (for the purpose of signing in-bound agreements). When an Inactive user is asked to sign an agreement, a new, single-use userID is created expressly for the purpose of signing that one agreement. The single-use userID is independent of the Inactive userID, and the account which governs it. This has several ramifications:
  • Agreements sent to an Inactive user can be signed, as the Inactive status does not apply to the single-use userID generated for the agreement.
  •  Agreements signed by the single-use userID are not assets of the Inactive userID and do not reside in the account of the Inactive userID.
  • Shares from the Inactive userID will not reflect agreements signed by single-use userIDs.
  • Reporting against the Inactive userID will not reflect agreements signed by the single-use userID.
  • If the Inactive userID is reactivated, they will not see the records of the agreements signed by the single-use userIDs on their Manage page.

There are two exceptions to the above behavior:

  • Agreements sent to the user before they were flagged as Inactive may not be signed (the agreement was already bound to the Inactive userID).
  • Users explicitly configured to not be allowed to sign agreements will continue to be disallowed any signing actions.

Inactive users are still prevented from logging in to the Adobe Sign system and sending agreements under their authority (by any method).

  • Improved security for web form access via password - Web forms have included a delay after a number of unsuccessful attempts to access a password-protected URL.
  • Aadhaar International Support – Customers from all Adobe Sign instances can now use the optional Aadhaar service as a digital signature provider. Previously it was only available to accounts on the IN1 instance. The Aadhaar add-on can be purchased at an additional cost per signature transaction.
  • Limited sharing of agreements - Agreement sharing has been capped when sharing the agreement to an external email address.
    • Multi-license accounts can share any one agreement up to ten times. 
    • Individual accounts can share an agreement up to 5 times.
    • Sharing an agreement with internal users is unrestricted.
  • Custom Company Name in Phone Authentication has been removed from service - The customizable company name value that could be inserted into the Phone Authentication method has been removed from service as announced in the June Technical Notification.
  • HIPAA-enabled accounts can now access the controls for images and links in recipient emails on the Global/Group Settings page.

Review the HIPAA related configurations here >

Image and Links to the agreement in email

  • The order that File Attachments are included in the final PDF has been updated to sort by page number first, and then field position second (when reading left to right; top to bottom)
  • The Replace Recipient feature on the new Manage page now allows the sender to include an optional message for the new recipient.

Review the Replace Recipient feature for more details >

Replace Recipient

  • External signers accessing completed agreements now must pass an authentication process when multi-factor authentication has been configured for the agreement (instead of being prompted to log in to Adobe Sign).
  • Web forms now report the field values of unverified web forms when accessing field data using the Download Form Field Data feature on the Manage page.

For more details on web forms >  

Download Form Field Data

API Updates

  • Read Agreement option for web forms - Two new REST v6 API calls are available to provide access to view web forms:
    • GET /widgets/<resourceId>
    • GET /widgets/<resourceId>/combinedDocument/url
  • GET/workflows/{workflowId} now returns the participant role in the response.

Resolved Issues

4292343 Improved signature clarity when using the TYPE signature option on mobile devices.
4295123 Fixed an issue that could prevent digital signatures from being visible when opening in a browser.
4299289 Improved the Replace Recipient experience by allowing the sender to include a message to the new recipient.
4299857 Fixed an issue that could cause a signed agreement to not apply the certificate seal.
4304261 Fixed an issue that could cause the Read Agreement option to not populate in the Options menu
4308516 Fixed an issue where users would continually be prompted to get admin consent when using OneDrive
4310225 Fixed an issue with agreements containing multiple signatures that would trigger a Server error : Error Message: The signature applied to this document is invalid. Please clear it and sign again.
4310416 Updated the v5 REST API to create users in an active state when created using POST /users
4311287 Fixed an issue where the Group navigation button would disappear on UMG enabled accounts after a users was removed from a group.
4311956 Fixed an issue where the designated font size for a field would not be reflected in the signer experience.
4312302 Fixed an issue that would remove the Reset Password option if the SAML mode was set to Mandatory.
4312735 Fixed an issue that would cause shared event notifications to be delivered when shared notifications were disabled.
4313025 Fixed an issue where a Form Filler role could not fill unassigned roles when Hybrid routing was enabled.
4313030 Fixed an issue where UMG enabled accounts would trigger an error using a custom workflow if the primary group of the sender is not allowed to send.
4313264 Updated the HIPAA enabled setting to permit access to the email link/image settings on the Global Setting page.
4315839 Corrected a problem with custom workflows that would not allow prefilling fields when the sender was also the second recipient.
4316058 Updated report field behavior to allow for leading zeros in text fields.
4317382 Corrected a problem with radio buttons showing the HTML code for apostrophes in the tool tip
4317978 Updated the way that File Attachments are ordered in the final PDF to group attachments based on the Page number of the field first, and the relative position of the field second (when reading left to right; top to bottom).
4318598 The GET/workflows/{workflowId} REST v6 API call now returns the participant role in the response.
4318606 The "Download Form Field Data" feature on the Manage page now returns field values for web forms that are not yet verified.
4318617 Fixed an issue where UMG enabled accounts would not allow a group admin to resend an invite.
4318679 Fixed an intermittent issue that could cause Written signature documents to fail to upload.
4318926 Corrected an issue that could trigger an  error (The cookie functionality is disabled on your browser) when generating an agreement form a mobile device.
4318991 Fixed an issue that could cause the max login failure setting to be ignored if SAML was set to Allowed.
4319068 External recipients now are required to pass a second factor authentication process (instead of logging in to Adobe Sign) to gain access to completed agreements when multi-factor authentication is configured.
4319422 Fixed an issue where a recipient could be replaced without confirming the password (for password authenticated agreement)
4319455 Fixed an issue in advanced sharing where settings might not be persistent after saving.
4320123 Fixed an issue that could trigger an error when attempting to View and Approve an agreement on the Manage page.
4320205 Fixed an issue that could prevent saving progress when pre-filling an agreement using advanced sharing.
4320542 Fixed an issue for UMG enabled accounts where all of a user's group affiliations could be removed if one group was removed using Search.
4321357 Fixed an issue that could trigger an error on the send page when KBA is selected for authentication, and "Require name on Send" is enabled.
4322445 Improved authoring to ensure consistent background coloring.
4322956 Fixed an issue with custom email templates where the recipients would not see the actual email address of the signer.
4323609 In Development - Fixed an issue where agreements completed by uploading a signed document would not trigger the AGREEMENT_WORKFLOW_COMPLETED webhook notification.
4323968 Improved the signature locking feature to include Typed signatures when the name value is supplied via profile or API.

Adobe Sign: October 2021  

Improved Functionality

  • Report Abuse Links - Small business and individual tier accounts now include a link for recipients to access a method to report potentially abusive activity regarding inbound agreement requests.
Report Abuse link in email

  • Notarize Integration - Adobe Sign integration with  Notarize, Inc.'s Remote Online Notarization(RON) platform allows customers to add remote online notarization service as part of their Adobe Sign transactions. Available for enablement for US customers in enterprise and business tiers sold directly by Adobe via the ETLA program. Notarize Transactions can be purchased as an add-on at an additional cost for these customers only.
    • Send page updates - Customers with notary enabled can select the Requires notarization option on the recipient record, just to the right of the authentication method:

Customers that use the embedded Send page in their applications or integrations will also have access to the notary functionality.

Notarize Interface on the Send page

After the agreement is configured and the sender clicks Next, the sender is presented with additional configuration options for the notarization process:

Configure Notarize options

  • API updates - There are significant updates to the APIs to support the Notarize Integration:

POST /agreements

The POST /agreements API has been updated to support sending an agreement for notarization.

  • A new role, NOTARY_SIGNER, should be used to indicate a notary session participant.
  • A new NotaryInfo attribute has been added to the AgreementInfo definition to contain all of the options associated with creating a new agreement that requires notarization.

Parameter Name

REST Object




Array of ParticipantInfo objects, containing participant-specific data (email, e.g.). All participants in the array belong to the same set.





Signs the Agreement


Approves the Agreement


One who herself can not sign but delegates the agreement to another signer


One who herself can not approve but delegates the agreement to another approver


Participant with whom this agreement has been shared


Participant to whom the Agreement was delegated. This role can not be used at the time of creating or updating agreement through POST/PUT call on agreement resource. Delegation happens separately by participants.


Notary Session Participant

Role assumed by all participants in the set (signer, approver, etc.)


FileInfo extension

The FileInfo definition will need to be expanded to indicate which documents should be notarized.


Parameter Name








A document that is associated with the agreement.
This field cannot be provided in POST call.
In case of GET call, this is the only field returned in the response




The unique label value of a file info element. In case of custom workflow this will map a file to corresponding file element in workflow definition.




ID for an existing Library document that will be added to the agreement




ID for a transient document that will be added to the agreement





Indicates that this document needs to be notarized.


ParticipantInfo extension

The ParticipantInfo definition has been expanded to allow the notary authentication method to be specified.


Parameter Name









Email of the participant.





MULTI_FACTOR_AUTHENTICATION - Notary authentication is performed using a two-factor authentication method
NONE - No authentication is required.



A new optionanotaryInfo field has been added to the AgreementInfo definition to contain the NotaryInfo object that specifies additional options associated with notarization.


Parameter Name







If only Notarize Notary on Demand Service is enable on the account,
then the notaryType will default to NOTARIZE_NOTARY, otherwise it will default to BYON_NOTARY


NOTARIZE_NOTARY - Notarize Service provides the notary
BYON_NOTARY - Account provides the notary





Only applies if type == NOTARIZE_NOTARY
BY_SENDER - Sender pays for the notarization
BY_SIGNER - Signer pays for the notarization










Notes for notary session.





email of the bring your own notary


Example /agreement

    "fileInfos": [
            "transientDocumentId": "{{transientDocumentId}}",
            "notarize": true
    "name": "notary_agreement_name",
    "participantSetsInfo": [
            "memberInfos": [
                    "email": "",
                    "securityOption": {
                        "notaryAuthentication": "MULTI_FACTOR_AUTHENTICATION"
            "order": 1,
            "role": "NOTARY_SIGNER",
            "name": "participant_set_name"
    "signatureType": "ESIGN",
    "state": "IN_PROCESS",
    "notaryInfo": {
        "appointment": "2021-10-29'T'13:00",
        "notaryEmail": "",
        "notaryType": "PROVIDER_NOTARY",
        "note": "This is a note for the notary.",
        "payment": "BY_SIGNER"


PUT|GET /agreements/{aid}

PUT /agreements/{aid} API will support updating an agreement with notarization options. GET /agreements/{aid} API will return any options set for agreement notarization. See POST /agreements section to view updated attributes.


Error Codes

Existing error codes for POST /agreements remain unchanged. We have defined a new error code as given below:

REST Error Code

HTTP Status Code





User setting or OAuth scope token do not permit sending agreement for notarization.

This error will be thrown when role is set to NOTARY_SIGNER and the API caller (i.e prospective sender) does not have notary feature enabled and/or if notary service provider is not set.


Documentation impact

In the request's AgreementInfo object, "status" element will include the new agreement status "WAITING_FOR_NOTARIZATION".


POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens

The API can be used by customers (notary signers) to obtain a signing token that allows them to complete the esign phase of the flow. 

  • New signing capability has been added to capture the new role - ACCEPT_BEFORE_NOTARIZATION. 
  • Signing tokens should not be obtained to complete the notarization phase.
  "securityInfo": {
  "authenticationMethod": "NONE"
  "signingCapabilities": [


PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status

The API can be used by customers (notary signers) to complete the esign phase of the flow. To accommodate the new role, new enum status value has been introduced - ACCEPTED_BEFORE_NOTARIZATION.














This status indicates that recipient with role SIGNER completed agreement.

This status indicates that recipient with role APPROVER completed agreement.

This status indicates that recipient with role ACCEPTOR completed agreement.

This status indicates that recipient with role CERTIFIED_RECIPIENT completed agreement.

This status indicates that recipient with role FORM_FILLER completed agreement.

This status indicates that recipient with role NOTARY_SIGNER completed agreement without notarizing it

The notary signer can follow the below sequence of API calls to complete the esign phase:

  1. GET /agreements/{agreementId}/members - to fetch the notary signer's participant ID & participant set ID
  2. POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens - to request signing token for notary signer with ACCEPT_BEFORE_NOTARIZATION capability
  3. POST /transientDocuments - to upload document that was reviewed
  4. PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status - to submit reviewed document and complete esign phase.

New webhook event

Customers can subscribe to new webhook event, AGREEMENT_READY_FOR_NOTARIZATION, to be notified when agreement is ready for notarization. The event is not visible on the webhooks UI & can be subcribed to via POST /webhooks API call.

Documentation impact

The following APIs are not modified but their documentation has been updated to include new agreement status "WAITING_FOR_NOTARIZATION" or new role "NOTARY_SIGNER".

GET /agreements

In response UserAgreements/UserAgreement object, "status" element now includes corresponding status "WAITING_FOR_NOTARIZATION".

GET /agreements/{agreementId}

In response AgreementInfo object, "status" element now includes corresponding status "WAITING_FOR_NOTARIZATION".

GET /agreements/{agreementId}/events

API is updated to support new READY_TO_NOTARIZE and NOTARIZED events.

In response Event object

  • "participantRole" element now includes new role NOTARY_SIGNER.
  • "type" element includes new events READY_TO_NOTARIZE and NOTARIZED. "description" element will be  "Document sent for notarization" and  "Notarized document received" respectively

GET /agreements/{agreementId}/members/participantSets/{participantSetId}

In response DetailedParticipantSetInfo object, "status" element now includes corresponding status "WAITING_FOR_NOTARIZATION".

PUT /agreements/{agreementId}

Request AgreementInfo object now includes "WAITING_FOR_NOTARIZATION" status.

PUT /agreements/{agreementId}/members/participantSets/{participantSetId}

WAITING_FOR_NOTARIZATION status is one of the "status" element values in the DetailedParticipantSetInfo object.

POST /agreements/{agreementId}/view

WAITING_FOR_NOTARIZATION status has been added as one of the allowed views.

GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo

If the participant specified in request path has notary signer role, the API will return ACCEPT_BEFORE_NOTARIZATION signing configuration, inline with all of the other signing configurations for this agreement/participant.

Resolved Issues

Issue Description
4308901 Corrected an issue where delegating an agreement with phone authentication would prompt an error if the delegated phone number had the same country code.
4314113 Fixed an issue where default expiration dates could not be edited by users when sending a new agreement
4318558 Corrected an issue where replacing a recipient with phone authentication would prompt a "The participant set ID specified is invalid" error
4319038 Fixed an issue where the Sender was not getting the option for 'External recipients Identity verification' when sending using the 'Send in Bulk' workflow.
4319798 Fixed an issue that could cause the selection of a radio button to jump cursor focus to a different field.
4320154 Fixed an issue that could prevent a library template from saving to a new group relationship.
4323013 Fixed an issue where opening a web form on the manage page would trigger an error: "The document is not yet available or will have no pages to view."
4323554 Fixed an issue where the event time/date stamps for updating admin rights could produce two records with the same time values.
4323609 Fixed an issue where uploading a signed agreement in the manage page would not trigger the AGREEMENT_WORKFLOW_COMPLETED webhook.
4325142 Fixed an issue where custom email templates would not reflect the correct name value for a participant if they canceled the agreement.
4326747 Fixed an issue that could result in the Send in Bulk page not completing the load process, omitting the Upload and Send actions.
4326855 Fixed an issue that could prevent recipients from declining the approval of an agreement.
4327000 Corrected an issue that could cause Smart-Id credentials to fail, with the error indicating that no algorithms were found.
Adobe logo

Sign in to your account