Your feedback is valuable and is vital in improving our product and documentation. Send suggestions to acrobatsignembed@adobe.com.
The Acrobat Sign Embed 2.0 frictionless model release exposes new APIs for streamlining account management as well as creating and validating new user tokens. Embed 2.0 provides the following benefits:
Seamless onboarding of new customers via the API
Partner ownership of all aspects of their end-customer relationship. End customers are not known to Adobe
Access to the Adobe Admin Console, Global Admin Console, and Developer Console
Support ticket access via the Admin Console
The ability to add, remove, and fully manage end-users independently from Adobe
Eliminates provisioning conflicts
Adobe provisions Embed 2.0 customers with access to both the Global and Admin Consoles so they can:
Use the consoles for managing all licensed Adobe products.
Create and assign roles for partner's users (e.g. developers; not customers).
Set up Federated directory and define Identity Provider (IdP).
Adobe creates and assigns a Sign 'channel' for exclusive partner use. All customer accounts will inherit from this channel's settings. You will collaborate with the Acrobat Sign partner team to define set of 'global' settings for all of your customers.
As described in the onboarding guide, creating a technical account involves these high level steps in the Developer Console:
Create a token for creating a new customer organization within Acrobat Sign.
Use your token for creating new users. Repeat as necessary.
Use the the technical account token in the Adobe Developer Portal, and generate a cURL to create an endpoint such as:
The rest of this document provides details about new Embed 2.0 APIs.
Base Endpoint API
Get Base_uri
Acrobat Sign APIs come with location awareness, so it's important to use the correct geographic access point when calling resource-based APIs to ensure success. We highly recommend that clients store the base endpoint URL for each environment. This way, you can retrieve the appropriate geographic access points (https://api.na1.adobesign.com, https://api.eu1.adobesign.com for your resource-based API calls. Before making any API calls, make sure to include the valid access point returned as part of the base endpoint API in your request.
The access point from where other APIs need to be accessed. In case other APIs are accessed from a different endpoint, it will be considered an invalid request.
webAccessPoint
String
Web access point acting as base host domain for all web-based calls.
Unsigned JWT token of the user with email as payload. Refer below section for more details.
Required
subject_token_type
String
jwt: subject token type
Required
actor_token_type
String
access_token - actor Token type
Required
actor_token
String
Technical account token with mandatory scope: sign_oem_user_impersonate.
Required
scope
String
Scopes requested for the user access token. It must be a subset of the scopes that are available in the technical account token: openid, AdobeID, agreement_read, agreement_sign, agreement_write, agreement_send, agreement_retention, agreement_vault, sign_library_read, sign_library_write, sign_library_retention, widget_read, widget_write, workflow_read, workflow_write, sign_user_write, sign_user_read, sign_user_login, sign_webhook_read, sign_webhook_write, sign_webhook_retention. The following scopes are not allowed for user access token: sign_account_read, sign_account_write, sign_oem_user_impersonate, ee.GROUP_SIGN_OEM, user_management_sdk.
Required
Generating Subject Token
Subject identifies the principal for which the JWT token https://jwt.io/introduction belongs & access token is being minted by exchanging technical account token(actor token). Subject is scoped to be locally unique in context of authorization server identified by email. The jwt token belonging to this subject is termed subject_token which is an unsigned one and has "email" as claim.
For quick testing, copy this sample value and paste in jwt.io, Navigate to right hand payload section & update "email". The jwt token at left side will be updated automatically. You can use this as subject token in token exchange api
How to generate programmatically?
You can use libraries https://jwt.io/libraries based on different languages to generate an unsigned subject token.
Account & User APIs: Common headers for Partner APIs
Header Name
Value
Description
Authorization
Bearer <Technical Account Token>
Technical account token that is generated by the partner and the Partner is onboarded beforehand.
content-type
application/json
Media type of the resource.
x-request-id
String
A string value needed to track a given request.
Common headers for Auth token APIs
Header Name
Value
Description
content-type
application/x-www-form-urlencoded
Media type of the resource.
x-request-id
String
A string value needed to track a given request.
Register APIs
Register APIs allow you to register your partner application with Acrobat Sign as part of the on-boarding process. Call this API directly with your technical account token for each technical account. You must also do this in the sandbox environment as well.
You can call the following API to register your partner application by directly using Technical account token:
Post Partners - Register the partner with Acrobat Sign
Partner will call this API to fetch paginated list of accounts for all their customers.
Request Header
Partner APIs Common Headers
Request Object
GetAccountsResponse
HTTP Status Code
200
Error Code
ErrorCodes - get Account
Query Params
Parameter Name
Type
Description
Needed
Data Range
pageNumber
Integer
pageNumber to navigate through pages
Optional
default:0<br/>•If pageNumber is less than 0, throw INVALID_PARAMETER exception
pageSize
Integer
pageSize to limit the number of records that will be fetched.
Optional
default:20 max:100<br/>•If pageSize is less than 1, throw INVALID_PARAMETER exception<br/>•If pageSize is more than 100, throw PAGE_SIZE_LIMIT_EXCEEDED exception
isLegacy
boolean
Return legacy accounts that are on old Sign Embed Models.
Optional
default:false<br/>•If isLegacy value is not a boolean, throw INVALID_PARAMETER exception
The API caller does not have the permission to execute this operation.
404
USER_NOT_FOUND
User does not exist.
500
INTERNAL_SERVER_ERROR
Some miscellaneous error has occurred.
Consumable APIs
Adobe Acrobat Sign supports a variety of authentication methods to ensure the security and integrity of electronic signatures. These methods range from simple, single-factor authentication to more complex, multi-factor authentication options - ensuring that organizations can manage and budget their use according to their security needs and compliance requirements, while also providing flexibility to choose the appropriate level of authentication for different types of transactions.
Phone Authentication: A six-digit code is sent to the recipient's phone via SMS or voice call, which must be entered to view the agreement. For details, check Phone authentication.
Knowledge-Based Authentication (KBA): This high-level authentication method is used mainly in financial institutions. It involves answering personal questions derived from public databases and is only available for recipients in the US. For details, check Knowledge-based authentication.
Government ID Authentication: This method requires the recipient to provide an image of a government-issued ID and a selfie for verification. For details, check Government ID.
data-slots=text
Add-ons and transactions are referred to as "consumables" because they are resources that are used up or consumed as they are utilized. Each time a transaction is initiated, such as sending an electronic document for signature, it is considered consumed and is deducted from the user's available transaction quota. Similarly, authentication services like Knowledge-Based Authentication or Phone Authentication are also treated as consumables, as they are used up on a per-recipient basis when employed in the signing process. This means that each time a recipient uses one of these methods, it counts against the total number of transactions available to the sender, which must be replenished as needed.
Consumables summary on integration
Value
HTTP Method
GET
Endpoint Operation
/v1/partners/me/consumableSummary
Authentication/ Authorization
Valid technical account token with ee.sign_group_oem
Audience
Partner will call this API to fetch count of consumables consumed within a given date range
Request Header
Partner APIs Common Headers
Query Params
FilterQueryParams
Response Object
ConsumableSummaryResponse
HTTP Status Code
200
Error Code
CommonErrorResponse
FilterRequestParams
Parameter Name
Type
Description
Required
Value Range
startDate
DateTime
DateTime in ISO-8601 format with UTC timezone
Yes
startDate should not be earlier than 2025-01-01T00:00:00Z
endDate
DateTime
DateTime in ISO-8601 format with UTC timezone
Yes
endDate should be greater than startDate but not more than 31 days from startDate. Ex: 2025-01-15T00:00:00Z
The API caller does not have the permission to execute this operation
429
TOO_MANY_REQUESTS
The request rate limit has reached
500
MISC_SERVER_ERROR
Some miscellaneous error has occurred.
Partner APIs Common Headers
Header Name
Values
Description
Authorization
Bearer <Technical Account Token>
Technical account token that is generated by the partner
content-type
application/json
Media type of the resource
x-request-id
String
A unique string value needed to track a given request
GDPR Delete userInfo
The GDPR Delete User API enables partners to delete end users in compliance with GDPR “Right to be forgotten” requirements. This removes the user in a manner that cannot be reversed or retrieved, addressing privacy and compliance issues.
Pre-requisites
A technical account with the scope sign_account_write_scope is required.
Only users having both Account Admin and Privacy Admin roles can delete users in their account.
The user that needs to be deleted must be marked as inactive.
Steps to delete a user:
Generate a technical account token.
Use this token to obtain a user embed token for the account admin who has both required roles.
Update the user status you want to delete to “INACTIVE.”
Call the GDPR Delete User API using the same embed token to permanently remove the user.
Delete userInfo as per GDPR compliance
Value
HTTP Method
DELETE
Endpoint Operation
/v1/users/{user_id}/userInfo
Authentication / Authorization
Valid OEM 2.0 user token<br/>Token user must have account_admin & privacy_admin role<br/>Token must have sign_user_write scope
Audience
Partner calls this API to delete their customers’ end users as per GDPR compliance
Request Header
Partner APIs Common Headers
Query Params
QueryParams
Response Object
ConsumableSummaryResponse
HTTP Status Code
202
Error Code
ErrorResponse
QueryParams
Parameter Name
Type
Description
Required
Default Value
Value Range
keepAgreements
Boolean
Flag whether user agreements be deleted or not
NO
True
True/False
Partner APIs Common Headers
Header Name
Values
Description
Authorization
Bearer <OEM user token>
OEM 2.0 user token exchanged through technical account token with valid scopes/roles.
content-type
application/json
Media type of the resource
x-request-id
String
A unique string value needed to track a given request
SuccessResponse
HTTP Status Code
202 (Accepted)
ErrorResponse
HTTP Status Code
Error Code
Message
400
INVALID_USER_ID
The specified path param ‘userId’ is invalid
400
INVALID_TOKEN
The token provided is invalid or expired.
403
PERMISSION_DENIED
The API caller does not have the permission to execute this operation.