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
One or more domains are not allowed for the given partner.
400
INVALID_JSON
An invalid JSON was specified.
400
MISSING_REQUIRED_PARAM
Required parameter <param name> is missing.
401
INVALID_ACCESS_TOKEN
Access token provided is invalid or has expired.
403
MISSING_SCOPES
The token does not contain the required scopes.
404
ORG_DOMAINS_NOT_FOUND
Org does not have any owned or trusted federated domains.
409
TECHNICAL_ACCOUNT_ID_ALREADY_EXISTS
Partner already exists for this Technical Account Id.
500
INTERNAL_SERVER_ERROR
Some miscellaneous error has occurred.
Account APIs
Call these APIs directly using a technical account token to create or update an account.
POST Account - To create a new account.
PUT Account - To update a new account.
GET Account - To fetch an account info.
GET All Accounts - To fetch all accounts in a channel.
Common account API header attributes
Common header attributes
Header Name
Values
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
The resource media type.
x-request-id
String
A string value needed to track a given request
Create Account
Overview
This API is idempotent. <br/> Repeating a create request with the same account name in the partner's channel returns 201 Created and the existing accountId. <br/> A 409 ACCOUNT_ALREADY_EXISTS error is returned when the name conflicts with an account in a different partner's channel.
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 pageSize specified must be greater than or equal to 1.
400
PAGE_SIZE_LIMIT_EXCEEDED
Page size has exceeded the maximum length of 100.
401
INVALID_TOKEN
The token provided is invalid or expired.
401
MISSING_SCOPES
The token does not contain the required scopes.
401
AUTHENTICATION_FAILED
Partner is not onboarded successfully.
403
PERMISSION_DENIED
The API caller does not have the permission to execute this operation.
500
INTERNAL_SERVER_ERROR
Some miscellaneous error has occurred.
User APIs
Call these APIs directly using a technical account token to create or update an account and users.
POST User - To add a user to an account.
PUT User - To update a user.
GET User - To fetch user info.
data-slots=text
Show Personalized/OEM email address everywhere <br/>OEM 2.0 partners can request a channel-level configuration that lets Acrobat Sign display a user’s actual company email address in the UI instead of the partner-managed email value used for provisioning and identity management. <br/>This behavior is not enabled by default. <br/>When enabled, emailAlias becomes required during user creation and must contain the user’s actual company email address. <br/>Partners interested in enabling this option must contact their PSM to request access. PSM and Security teams will review eligibility.
Common user API header attributes
Common user header attributes are identical to the Account APIs.
POST user
Overview
This API is idempotent.<br/> Repeating a create request with the same email in the same account returns 201 Created and the existing userId. <br/>A 409 USER_ALREADY_EXISTS error is returned when the email conflicts with a user in a different account.
Item
Value
HTTP Method
POST
Endpoint Operation
{apiAccessPoint}/api/gateway/signembed/v1/users
Authentication/ Authorization
Valid Technical Account Token or Sign Embed user Admin token. Mandatory Scopes required in token: sign_user_write.
Audience
Partner will call this API to add a new user to their customer's account.
Request Header
Partner APIs Common Headers
Request Object
Create User Request
Response Object
Create User Response
HTTP Status Code
201
Error Code
ErrorCodes - Create User
Request
Create-update user request parameters
Parameter Name
Type
Default Value
Description
Mandatory Fields by POST/PUT
Update Allowed via PUT
id
String
Id to uniquely identify a user.
Required and permitted only in a PUT call
Immutable
email
String
Email of the user.
Required
Mutable
emailAlias
String
Email alias with customer domain displayed in the audit report.
Optional
Mutable
firstName
String
First Name of the User.
Required
Mutable
lastName
String
Last Name of the User.
Required
Mutable
accountId
String
Account ID where the user needs to be added.
Required. Optional if User token is used for Authentication.
Immutable
status
String
ACTIVE
Status of the user.
Optional. Not supported in POST. Defaults to ACTIVE.
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.