> You are reading the Docusign Developer Documentation. For clean Markdown of any page, append .md to the page URL. > > Documentation indexes by section: > - APIs and SDKs: https://docusign.docs.buildwithfern.com/docs/llms.txt > - Platform 101: https://docusign.docs.buildwithfern.com/platform/llms.txt > - Extension Apps: https://docusign.docs.buildwithfern.com/extension-apps/llms.txt > - Docusign CLI: https://docusign.docs.buildwithfern.com/docusign-cli/llms.txt > > Authentication (OAuth, JWT Grant, M2M): https://docusign.docs.buildwithfern.com/platform/auth > Webhooks and Connect: https://docusign.docs.buildwithfern.com/platform/webhooks > > OpenAPI specifications: https://docusign.docs.buildwithfern.com/openapi.json > MCP server: https://docusign.docs.buildwithfern.com/_mcp/server # Platform glossary > Defines common terms used throughout the Docusign platform developer documentation. 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](/platform/auth) 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](/platform/glossary#jwt-grant) to impersonate a user with account admin or [organization](/platform/glossary#organization) privileges. See [Application-access tokens](/docs/admin-api/admin101/application-auth) 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](/platform/glossary#envelope), and has specific settings, [templates](/platform/glossary#template), [brands](/platform/glossary#brand), billing, and usage. An [organization](/platform/glossary#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](/docs/admin-api/admin101/concepts/data-model) for details. ## Alert A Monitor API *alert* is a notification that is generated when [events](/platform/glossary#event) occur that meet certain criteria. Alerts enable your organization to monitor and address security issues. See [Events and alerts](/docs/monitor-api/monitor101/events-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](https://admindemo.docusign.com/authenticate?goTo=appsAndKeys) page. See [Configure your app](/platform/configure-app) for details. ## App An *app* in the Docusign platform is a set of parameters that are used to identify and configure an [integration](/platform/glossary#integration)'s access to the Docusign platform. Each app has exactly one [integration key](/platform/glossary#integration-key). See [Configure your app](/platform/configure-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](/platform/glossary#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](/platform/auth/authcode) for details. ## Base URI A base URI, together with your [API Account ID](/platform/glossary#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](/platform/glossary#integration) 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](/platform/auth/reference/user-info) or look in your [Apps and Keys](https://admindemo.docusign.com/authenticate?goTo=appsAndKeys) 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](/docs/esign-rest-api/esign101/concepts/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](/platform/glossary#clickwrap). 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](/docs/click-api/click101/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](/docs/click-api/click101) for details. ## Clickwrap version Docusign automatically versions your [clickwraps](/platform/glossary#clickwrap). 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](/docs/click-api/how-to/elastic-template-versioning) for details. ## Client ID When you use a [clickwrap](/platform/glossary#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](/docs/click-api/how-to) for details. ## Company A Rooms API *company* is a container for regions and offices, and may be associated with [rooms](/platform/glossary#room), [roles](/platform/glossary#role), and [users](/platform/glossary#user). Docusign sets up your company in Rooms as part of the account activation process. See [Rooms concepts](/docs/rooms-api/rooms101/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](/platform/glossary#envelope) status. See [Docusign Connect](/platform/webhooks/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](/platform/glossary#document) 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](/platform/account) for details. ## Document A *document* contains the content for a [recipient](/platform/glossary#envelope-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](/docs/esign-rest-api/esign101/concepts/documents) for details. ## Domain Admin API *domains* are [organization](/platform/glossary#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](/docs/admin-api/admin101/concepts/data-model) for details. ## Embedded sending *Embedded sending* (also called the *envelope sender view* of an [envelope](/platform/glossary#envelope)) enables users to edit the [tabs](/platform/glossary#tab), [documents](/platform/glossary#document), [recipients](/platform/glossary#envelope-recipient), and other settings of draft Docusign envelopes within your [app](/platform/glossary#app) before sending them out for approval. See [Embedded signature and elastic signing with eSignature (Embedded Signing)](/docs/esign-rest-api/esign101/concepts/embedding) for details. ## Embedded signing *Embedded signing* (also called the *envelope recipient view* of an [envelope](/platform/glossary#envelope)) enables users to view and sign [documents](/platform/glossary#document) directly through your [app](/platform/glossary#app) or website. See [Embedded signing](/docs/esign-rest-api/esign101/concepts/embedding) for details. ## Envelope An *envelope* is an overall container for a Docusign transaction. An `envelope` object contains: * One or more [documents](/platform/glossary#document) that will be sent for electronic signature * Information about the sender * Information about the [recipients](/platform/glossary#envelope-recipient), 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](/docs/esign-rest-api/esign101/concepts/envelopes) for details. ## eSignature Admin You can use [eSignature Admin](https://admindemo.docusign.com/) to manage your Docusign account, [integrations](/platform/glossary#integration), 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](/platform/glossary#envelope-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](/docs/idevidence-api/how-to/retrieve-idevidence-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](/platform/glossary#envelope). These events can be tracked for security purposes and can trigger [alerts](/platform/glossary#alert). See [Events and alerts](/docs/monitor-api/monitor101/events-alerts) for details. ## Field Also known as a [tab](/platform/glossary#tab), a *field* is a place in a [document](/platform/glossary#document) where a [recipient](/platform/glossary#envelope-recipient) may provide input, such as a signature, or where a calculated value (such as a formula) is displayed. After all [envelope](/platform/glossary#envelope) recipients complete all of their fields/tabs on all of the documents, the signing process is complete. See [Tabs](/docs/esign-rest-api/esign101/concepts/tabs) for details. ## Fieldset A Rooms API *fieldset* is a preconfigured set of fields that appears on a [room](/platform/glossary#room)’s Details tab, such as Contact Name and Phone. See [Rooms concepts](/docs/rooms-api/rooms101/concepts) for details. ## Form A Rooms API *form* is a standard preset document imported to your [company](/platform/glossary#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](/docs/rooms-api/rooms101/forms) for details. ## Go-Live When you are ready to launch your [integration](/platform/glossary#integration) into a production environment, you will need to *go-live*. To go-live, you will move your [application](/platform/glossary#app) from the Docusign developer account to a Docusign production account. See [Go-Live](/platform/go-live) for details. **Note:** When you go-live to move your app to the production environment, its [integration key](/platform/glossary#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](/platform/glossary#envelope-template) sharing to limit user access to templates. Additionally, if multiple account [brands](/platform/glossary#brand) are enabled, groups are used to set which brands can be used by group members. See [Groups](https://support.docusign.com/s/document-item?language=en_US\&rsc_301\&bundleId=pik1583277475390\&topicId=cuv1583277363488.html&_LANG=enus) for details. ## ID Verification (IDV) *ID verification* enables you to verify the identity of [recipients](/platform/glossary#envelope-recipient) based on government photo IDs (such as a driver’s license or passport) and electronic IDs. See [Recipient authentication](/docs/esign-rest-api/esign101/concepts/recipients/auth) for details on [ID Verification (IDV)](/docs/esign-rest-api/how-to/id-verification) and other recipient authentication options. ## Implicit Grant The *Implicit Grant* is an OAuth 2.0 flow that is used to grant an [access token](/platform/glossary#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](/platform/auth/implicit) for details. ## Integration An *integration* is a software application that incorporates Docusign API functionality. See [Build a Docusign integration](/platform/build-integration) for details. ## Integration key Each of your [integration](/platform/glossary#integration)s that uses the Docusign platform is identified by one or more *integration keys*. An integration key is a [GUID](http://guid.one/) 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](/platform/configure-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](/docs/notary-api/notary101/concepts/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](/docs/notary-api/notary101/concepts/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](/platform/glossary#access-token) to service [integration](/platform/glossary#integration)s. 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](/platform/auth/jwt) for details. ## Media An ID Evidence *media* API call returns configured ID verification image data that was captured for a corresponding [event](/platform/glossary#event). For example, media is stored for an event that is generated as a result of a [recipient](/platform/glossary#envelope-recipient)'s passport verification. See [How to retrieve ID Evidence media](/docs/idevidence-api/how-to/retrieve-idevidence-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](/docs/notary-api/notary101/concepts/notary-pool) for details. ## Organization An Admin API *organization* contains [accounts](/platform/glossary#account), [domains](/platform/glossary#domain), and the [users](/platform/glossary#admin-api-user) 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](/docs/admin-api/admin101/concepts/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](/docs/esign-rest-api/esign101/concepts/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](/docs/esign-rest-api/esign101/concepts/permissions) for details. ## Recipient ### Envelope recipient A *recipient* is a person who receives a Docusign [envelope](/platform/glossary#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](/docs/esign-rest-api/esign101/concepts/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](/docs/notary-api/notary101/concepts/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](/platform/glossary#authorization-code-grant) or [Implicit Grant](/platform/glossary#implicit-grant) authentication flow. If your [integration](/platform/glossary#integration) is using the [JSON Web Token (JWT) Grant](/platform/glossary#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](/platform/glossary#app). For details, see [Configure your app](/platform/configure-app). ## Refresh token A *refresh token* is a special token returned after authenticating using [Authorization Code Grant](/platform/glossary#authorization-code-grant). You can quickly exchange a refresh token for a new [access token](/platform/glossary#access-token). See [Use refresh tokens](/platform/auth/confidential-authcode-get-token#use-refresh-tokens) for details. ## Responsive signing *Responsive signing* is a feature that enables you to use HTML pages as signing [Documents](/docs/esign-rest-api/esign101/concepts/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](/docs/esign-rest-api/esign101/concepts/responsive) for details. ## Role A Rooms API *role* defines a set of permissions and can be internal, for users inside your [company](/platform/glossary#company), or external, for users outside your company. See [Rooms concepts](/docs/rooms-api/rooms101/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](/platform/glossary#document), and stages. See [Rooms concepts](/docs/rooms-api/rooms101/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](/platform/glossary#room) using the Rooms API, you standardize the tasks that must be completed for the transaction. See [Using room templates and task lists](/docs/rooms-api/rooms101/templates) for details. ## RSA key pair An *RSA key pair* is used to encrypt your token in the [JSON Web Token (JWT) Grant](/platform/glossary#jwt-grant) authentication flow to provide assurances of authorship and data integrity. See [Configure your app](/platform/configure-app) for details. ## Scope Each time your [integration](/platform/glossary#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](/platform/auth/reference/scopes). ## Signing group *Signing groups* enable you to send an [envelope](/platform/glossary#envelope) to a predefined group of [recipients](/platform/glossary#envelope-recipient) and have any one member of the group sign your [documents](/platform/glossary#document). 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](https://support.docusign.com/s/document-item?bundleId=gav1643676262430\&topicId=zgn1578456447934.html&_LANG=enus\&language=en_US\&rsc_301) 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](/docs/esign-rest-api/esign101/concepts/responsive) for details. ## Tab A *tab* is a place in a [document](/platform/glossary#document) where a [recipient](/platform/glossary#envelope-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](/platform/glossary#field). After all [envelope](/platform/glossary#envelope) recipients complete all of their tabs on all of the documents, the signing process is complete. See [Tabs](/docs/esign-rest-api/esign101/concepts/tabs) for details. ## Template ### Composite template A *composite template* is a collection of multiple [templates](/docs/esign-rest-api/esign101/concepts/templates) that can be applied together to [envelopes](/platform/glossary#envelope). See [Composite templates](/docs/esign-rest-api/esign101/concepts/templates/composite) for details. ### Envelope template A *template* is an object that contains an [envelope](/platform/glossary#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](/platform/glossary#document), or send different documents to the same group of people. See [Templates](/docs/esign-rest-api/esign101/concepts/templates) for details. ### Room template A Rooms API *template* holds [room](/platform/glossary#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](/docs/rooms-api/rooms101/templates) for details. ## Transaction side Under the Rooms API data model, a *transaction side* is the part your [company](/platform/glossary#company) plays in the transaction, such as buy or sell. See [Rooms concepts](/docs/rooms-api/rooms101/concepts) for details. ## User ### Admin API user An Admin API *user* represents an individual Docusign user in your [organization](/platform/glossary#organization). Users may be present in one or more [accounts](/platform/glossary#account) and may be associated with a reserved [domain](/platform/glossary#domain). See [Admin API data model](/docs/admin-api/admin101/concepts/data-model) for details. ### Rooms API user A Rooms API *user* is an individual who has been invited to your [company](/platform/glossary#company), or to a [room](/platform/glossary#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](/docs/rooms-api/rooms101/concepts) for details. ## User ID A GUID value that uniquely identifies a Docusign user. See [Configure your app](/platform/configure-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](https://support.docusign.com/s/document-item?bundleId=gmi1660583110357\&topicId=brp1660583998599.html). See [Web form configurations](/docs/web-forms-api/web-forms-101/concepts#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](/docs/web-forms-api/web-forms-101/concepts#web-form-instances) for details.