Platform glossary
This page defines common terms used throughout the Docusign platform.
Access token
Regardless of the way you authenticate, you receive an access token. If you include this access token in an API request, your request is authenticated and access to the API is granted. See Authenticate for details.
Application-access token
An application-access token is an access token that represents an application instead of an account user. Application-access tokens can be used only for a limited set of Admin API endpoints that manage users and Docusign objects that don’t belong to a specific user. They are an alternative to using the JWT Grant to impersonate a user with account admin or organization privileges. See Application-access tokens for details.
User-access token
A user-access token is an access token that impersonates an account user.
Account
An Admin API account contains users and envelopes, and has specific settings, templates, brands, billing, and usage. An organization can export settings for any of its accounts, enabling easy auditing, troubleshooting, and sharing setting changes to any other account in the organization. See Admin API data model for details.
Alert
A Monitor API alert is a notification that is generated when events occur that meet certain criteria. Alerts enable your organization to monitor and address security issues. See Events and alerts for details.
API account ID
An API account ID is a GUID that identifies your account. Most Docusign API calls include this value (also called account ID) as the accountId parameter in the call’s path. You can find your API Account ID on the Apps and Keys page. See Configure your app for details.
App
An app in the Docusign platform is a set of parameters that are used to identify and configure an integration’s access to the Docusign platform. Each app has exactly one integration key. See Configure your app for details.
Authorization Code Grant
The Authorization Code Grant is an OAuth 2.0 flow used by server-hosted applications to obtain an access token.
In the Authorization Code Grant flow, your client application requests an authorization code that can be exchanged for the access token that it needs to make API calls. See Authorization Code Grant for details.
Base URI
A base URI, together with your API Account ID, is needed to construct the full path of a Docusign API call. For example:
{base_uri} + "/restapi/v2.1/accounts/" + {account_id}
- For integrations in the development (demo) environment, the base URI is
https://demo.docusign.net/ - For integrations in production, the base URI will be in the form of
https://{server}.docusign.net/
To find your base URI, you can call the UserInfo endpoint or look in your Apps and Keys page.
Brand
A brand is a collection of settings that determine how your organization’s branding elements (such as colors and logos) are applied to your account’s sending and signing experience. See Branding for details.
Click event callback
When developing for the Docusign Click API, you may need to handle various events generated by your users interacting with clickwraps. You can modify your web application to react to these events by implementing click event callbacks, which are client-side functions that are automatically called when their associated events occur. Because the callbacks are client-side, you must use JavaScript that runs in the browser to handle the triggering events. See Click event callbacks for details.
Clickwrap
The Click API is built around a core object called a clickwrap. A clickwrap is an iframe that displays your terms to your customers for them to review and accept. See Click API 101 overview for details.
Clickwrap version
Docusign automatically versions your clickwraps. The first clickwrap you create becomes version 1 (V1). Updating a clickwrap automatically creates a new version (V2, and so on). You can configure your clickwrap settings to prompt users to agree to the updated terms the next time they log in. See How to create a new elastic template version for details.
Client ID
When you use a clickwrap, you specify a clientUserId that uniquely identifies the user. This value can be any identifier that your own system uses to track individual users. Examples include employee IDs, email addresses, and surrogate key values. Click uses this identifier in combination with other information to determine whether a user has already accepted the clickwrap agreement, and also to report on user responses. See the Click API How-to guides for details.
Company
A Rooms API company is a container for regions and offices, and may be associated with rooms, roles, and users. Docusign sets up your company in Rooms as part of the account activation process. See Rooms concepts for details.
Connect
Docusign Connect is a service that enables your applications to subscribe to Docusign to receive real-time updates on events and changes in envelope status. See Docusign Connect for details.
Developer account
Developer accounts (also called demo accounts) enable you to test and develop with Docusign functionality for free. Developer accounts operate in the Docusign development (demo) environment, which is identical to production except:
- Documents sent in this environment are not legally binding.
- Documents sent in this environment have test stamps applied to them.
- Developer accounts do not expire.
- Developer accounts have enterprise-level features enabled for development and testing purposes.
See Developer account for details.
Document
A document contains the content for a recipient to review or sign. Docusign supports documents in a variety of file formats, including PDF, Word, and HTML. A document object also contains metadata such as the file extension, file name, and document ID. See Documents for details.
Domain
Admin API domains are organization-specific reserved internet domains, such as @exampledomain.com. You can define policy settings for users of each reserved domain within your organization, export lists of domain users for audit purposes, and manage domain users. See Admin API data model for details.
Embedded sending
Embedded sending (also called the envelope sender view of an envelope) enables users to edit the tabs, documents, recipients, and other settings of draft Docusign envelopes within your app before sending them out for approval. See Embedded signature and elastic signing with eSignature (Embedded Signing) for details.
Embedded signing
Embedded signing (also called the envelope recipient view of an envelope) enables users to view and sign documents directly through your app or website. See Embedded signing for details.
Envelope
An envelope is an overall container for a Docusign transaction. An envelope object contains:
- One or more documents that will be sent for electronic signature
- Information about the sender
- Information about the recipients, including authentication requirements and the areas where they need to provide input
- The content of the email notification that recipients receive
- Status information that tracks delivery and signature progress
See Envelopes for details.
eSignature Admin
You can use eSignature Admin to manage your Docusign account, integrations, users, and other settings.
Event
ID Evidence API event
An ID Evidence events API call returns a log of all state changes to an envelope’s recipient during the ID verification process and stores the selected text-based data, such as name, date of birth, and more. See How to retrieve ID Evidence events for details.
Monitor API event
A Monitor API event is an action taken by a user, administrator, or API connected to your organization, such as adding a user or creating an envelope. These events can be tracked for security purposes and can trigger alerts. See Events and alerts for details.
Field
Also known as a tab, a field is a place in a document where a recipient may provide input, such as a signature, or where a calculated value (such as a formula) is displayed. After all envelope recipients complete all of their fields/tabs on all of the documents, the signing process is complete. See Tabs for details.
Fieldset
A Rooms API fieldset is a preconfigured set of fields that appears on a room’s Details tab, such as Contact Name and Phone. See Rooms concepts for details.
Form
A Rooms API form is a standard preset document imported to your company’s Rooms account for easy reuse. These documents are typically association forms or other documents required for legal compliance in real estate transactions. See Forms for details.
Go-Live
When you are ready to launch your integration into a production environment, you will need to go-live. To go-live, you will move your application from the Docusign developer account to a Docusign production account. See Go-Live for details.
Note: When you go-live to move your app to the production environment, its integration key is duplicated in the production environment rather than moved. This means you can continue to use that integration key in the development (demo) environment as well as in production.
Group
Groups are used to organize users into functional units for template sharing to limit user access to templates. Additionally, if multiple account brands are enabled, groups are used to set which brands can be used by group members. See Groups for details.
ID Verification (IDV)
ID verification enables you to verify the identity of recipients based on government photo IDs (such as a driver’s license or passport) and electronic IDs. See Recipient authentication for details on ID Verification (IDV) and other recipient authentication options.
Implicit Grant
The Implicit Grant is an OAuth 2.0 flow that is used to grant an access token to user applications that are not able to store sensitive data on a secure server, such as those that are native to mobile devices.
In the Implicit Grant flow, your application requests an access token directly. This is potentially less secure because the access token must be stored on the user’s device, but it does not require that the application have access to a web server.
See Implicit Grant authentication for details.
Integration
An integration is a software application that incorporates Docusign API functionality. See Build a Docusign integration for details.
Integration key
Each of your integrations that uses the Docusign platform is identified by one or more integration keys. An integration key is a GUID value that identifies your integration (or, in specific cases, a website, system, or scenario within your integration) and links to its configuration values.
See the Integration Key section of Configure your app for details.
Journaling
Journaling refers to the process of creating journal entries for recording the actions of a Notary API notary session. See Journaling for details.
Jurisdiction
A jurisdiction is the state in which a notary session is completed. The Notary API tracks the jurisdiction, enabling you to record which state-specific requirements and processes were used for notarization. See Jurisdiction for details.
JWT Grant
The JSON Web Token (JWT) Grant is an OAuth 2.0 flow that is used to grant an access token to service integrations. In the JWT Grant authentication flow, your integration posts a JWT to the Docusign authentication service, asserting its credentials and providing the data of the user that it wishes to impersonate (act on behalf of). Docusign validates that the assertion is signed and that your integration has the permission to act on behalf of the user, then issues an access token that allows you to call Docusign APIs.
See JWT Grant authentication for details.
Media
An ID Evidence media API call returns configured ID verification image data that was captured for a corresponding event. For example, media is stored for an event that is generated as a result of a recipient’s passport verification. See How to retrieve ID Evidence media for details.
Notary pool
A notary pool is a set of users who can serve as notaries in a Notary API remote notary session initiated by your organization. See Notary pool for details.
Organization
An Admin API organization contains accounts, domains, and the users within those accounts and domains. An organization administrator can perform operations to add, update, or close any users within any of the organization’s accounts or reserved domains from one place, rather than performing these operations for each account individually. See Admin API data model for details.
Permission
A permission enables or blocks access to a specific feature or capability of the Docusign platform. Permissions are defined and assigned to users by applying permission profiles such as DS Admin or DS Sender. See Permissions for details.
Permission profile
Users defined in Docusign accounts each have a permission profile that determines which actions they are allowed to perform. See Permissions for details.
Recipient
Envelope recipient
A recipient is a person who receives a Docusign envelope. Each envelope object must contain at least one recipient. Each recipient has a recipient type that defines their role in the signing process. For example, a recipient might be a signer, witness, or carbon copy recipient. See Recipients for details.
Notary recipient
A notary recipient is a specialized type of recipient specific to the Notary API. The notary is always invited to join a notarization session first, before the rest of the recipients, ensuring that the notary will be present to observe the other recipients’ activity. See Notary recipients for details.
Redirect URI
The redirect URI is the URI (URL) to which Docusign will redirect the browser after authentication when using the Authorization Code Grant or Implicit Grant authentication flow. If your integration is using the JSON Web Token (JWT) Grant flow, a redirect URI is also used for the individual consent process.
You must define at least one redirect URI to implement any authentication scenario. You may set more than one redirect URI per app. For details, see Configure your app.
Refresh token
A refresh token is a special token returned after authenticating using Authorization Code Grant. You can quickly exchange a refresh token for a new access token. See Use refresh tokens for details.
Responsive signing
Responsive signing is a feature that enables you to use HTML pages as signing Documents by passing in a standard PDF or other supported file type, which is automatically converted into HTML, or by defining the signing document directly in HTML. See Responsive signing for details.
Role
A Rooms API role defines a set of permissions and can be internal, for users inside your company, or external, for users outside your company. See Rooms concepts for details.
Room
A room is a secure workspace in the Docusign Agreement Cloud that’s associated with a specific Rooms API transaction. Rooms enable you to streamline complex agreements that include multiple parties, documents, and stages. See Rooms concepts for details.
Room task list
A room task list holds a checklist of steps for a common transaction type. By specifying a task list when you create a room using the Rooms API, you standardize the tasks that must be completed for the transaction. See Using room templates and task lists for details.
RSA key pair
An RSA key pair is used to encrypt your token in the JSON Web Token (JWT) Grant authentication flow to provide assurances of authorship and data integrity. See Configure your app for details.
Scope
Each time your integration begins an OAuth flow, it must request one or more scopes. A scope is a set of permissions for an API that specifies what endpoints and methods your integration can call. Each scope is specific to a Docusign API. For example, you must request the signature scope to perform most operations on the eSignature REST API.
To see the full list of all supported scopes, see Authentication scopes.
Signing group
Signing groups enable you to send an envelope to a predefined group of recipients and have any one member of the group sign your documents. When you send an envelope to a signing group, anyone in the group can open it and sign it with their own signature. See Signing groups for details.
Smart sections
The smart sections feature optimizes document display on mobile devices through the use of collapsible sections, rotating tables, and Continue buttons. You can use smart sections with documents that Docusign converts to HTML and documents that you create directly in HTML. See Responsive signing for details.
Tab
A tab is a place in a document where a recipient may provide input, such as a signature, or where a calculated value (such as a formula) is displayed. Tabs are also referred to as tags or fields. After all envelope recipients complete all of their tabs on all of the documents, the signing process is complete. See Tabs for details.
Template
Composite template
A composite template is a collection of multiple templates that can be applied together to envelopes. See Composite templates for details.
Envelope template
A template is an object that contains an envelope definition and can be used as a blueprint to create one or more envelopes using its stored information. Templates streamline the sending process when you frequently send the same or similar documents, or send different documents to the same group of people. See Templates for details.
Room template
A Rooms API template holds room information and tasks for room participants. By specifying a template when you create a room, you can automatically import this data. See Using room templates and task lists for details.
Transaction side
Under the Rooms API data model, a transaction side is the part your company plays in the transaction, such as buy or sell. See Rooms concepts for details.
User
Admin API user
An Admin API user represents an individual Docusign user in your organization. Users may be present in one or more accounts and may be associated with a reserved domain. See Admin API data model for details.
Rooms API user
A Rooms API user is an individual who has been invited to your company, or to a room. A company user is a member of your organization’s internal staff. A rooms user has been invited to a specific room, or is the creator of the room. See Rooms concepts for details.
User ID
A GUID value that uniquely identifies a Docusign user. See Configure your app for details.
Web form configuration
A web form configuration defines the sequence of pages, text and fields on the pages, validation, and conditional logic for a Web Form. See Web form configurations for details.
Web form instance
A web form instance is created from a web form configuration and is displayed in a browser to a user, who populates the fields and submits the form instance. See Web form instances for details.