> 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 # Docusign objects > Learn about the basic concepts and objects used by the Docusign platform. Each API in the Docusign platform defines and uses a set of concepts and core objects that are used as the basis for its functionality. Each core concept and object is described in the section corresponding to the API which implements it. * The *eSignature API* enables you to use a wide range of functionality centered around electronic signature. * The *Web Forms API* enables you to create and manage the web form instances that users fill out. You can also use the API to retrieve data about the web form configurations that are available in your Docusign account. * The *Click API* enables companies to capture consent to standard agreement terms with a single click. * The *Docusign Admin API* centralizes the management of Docusign users, accounts, and single sign-on (SSO). * The *Rooms API* simplifies complex agreements by bringing together each person involved with a transaction in a digital space called a room where every detail, task, and transaction document is centrally located and managed. * The *Monitor API* helps organizations protect their agreements with round-the-clock activity tracking. * The *ID Evidence API* enables Docusign customers using [ID Verification (IDV)](/docs/esign-rest-api/how-to/id-verification) to retrieve the data that can be stored while verifying a signer’s ID. * The *Notary API* enables you to have your documents notarized remotely online for all parties involved by having a notary public act as an in-person (online) witness to the electronic signing. * The *Workflow Builder API* enables you to create and manage branching end-to-end workflows that can extend beyond getting an agreement through eSignature. * The *Agreement Manager API* enables you to centrally store, manage, and analyze your agreements with help from AI. * The *Connected Fields API* enables your extension apps to verify and autofill custom field data in real time during signing. * The *Workspaces API* enables you to create and manage workspaces, which are digital places where you can bring people, agreements, and information together for your transactions. #### eSignature REST API concepts ### Envelopes 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 ### Recipients 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. You associate each recipient with one or more tabs, or places in a document where they may provide input. ### Tabs 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. There are several types of tabs, each of which is designed for a specific kind of input. For example, a Sign Here tab requires a signature, while a Text tab prompts the user to enter text. For more information, see [tab types](/docs/esign-rest-api/reference/envelopes/enveloperecipienttabs#tab-types). ### Documents 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. ### Templates A *template* is an object that stores envelope information, enabling you to use it as a blueprint to create any number of envelopes with that data. Templates streamline the sending process when you frequently send the same or similar documents, or send different documents to the same group of people. ### Composite templates You can apply multiple templates (or combine templates with forms or other documents) to a single envelope by using a *composite template*. ### Account An *account* is a container created for a Docusign customer (either a company or an individual) that includes their envelopes, user memberships, templates, app integration settings, and other customer data. An account provides access to Docusign services based on a subscription plan and its associated features. An organization may have one or more accounts. ### eSignature administrator An *eSignature (account) administrator* manages a single customer account. eSignature administrators can change settings within an account, manage user memberships and access controls, and perform other administrative tasks. #### Web Forms API concepts ### Web form configurations Each Web Form has one *web form configuration* that defines the form's sequence of pages, text and fields on the pages, validation, and conditional logic. You create web form configurations in the [Web Forms builder](https://support.docusign.com/s/document-item?bundleId=gmi1660583110357\&topicId=gpc1660591510274.html). ### Web form instances After you've created a web form configuration and activated it, you can create *web form instances* from that configuration via Web Forms API requests. Web form instances are displayed in a browser to users, who populate the fields and submit the form instances. Each instance has a unique, secure URL. The fields in a web form instance can be prefilled with values supplied in the API request that creates the instance. After a user has submitted a form instance, your application can retrieve the submitted field values, whether prefilled or user-populated. #### Click API concepts ### Elastic template The Click API is built around a core object called an elastic template. An *elastic template* is an iframe that displays your terms to your customers for them to review and accept. You can display an elastic template as a modal (a window positioned over your page), or inline as part of your page. ### Elastic template versions Docusign Click automatically versions your elastic templates. The first elastic template you create becomes version 1 (**V1**). Updating an elastic template automatically creates a new version (**V2**, and so on). You can configure your elastic template settings to prompt users to agree to the updated terms the next time they log in. The version number for each elastic template displays in the **Version** column on your dashboard in the UI. ### Client ID When you use a elastic template, 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 elastic template agreement, and also to report on user responses. #### Docusign Admin API concepts ### Organization An *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. * You can manage account settings, domain settings, and users within accounts through the organization to which they belong. * Organizations may reserve domains. * Organizations may be linked with one or more accounts. ### Organization administrator An *Organization administrator* manages Docusign settings for their organization, including one or more accounts, domains, and any users within those accounts and domains. ### Account *Accounts* contain users and envelopes, and have 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. * Accounts are linked to an organization. * You can perform operations to add/update/close account users, and change account settings within your organization. * An account can only have one organization. ### Domain *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. * Domains may be claimed by an organization. * When a domain is claimed by an organization, all users within that domain are added to the organization, even if they have trial or free accounts. * You can set domain controls for all users of the domain. * You can export information about your organization’s users that are associated with your reserved domains. ### User *Users* represent individual Docusign users in your organization. Users may be present in one or more accounts and may be associated with a reserved domain. * Users must be members of at least one account within an organization. * Users may be part of a domain reserved to the organization. * If a user is a member of multiple accounts, their information is present in each account. * If a user is part of a reserved domain then they are a user within the organization. * You can query, add, update, or close users through their associated account or domain. #### Rooms API concepts ### Rooms A *room* is a secure workspace in the Docusign Agreement Cloud that is associated with a specific transaction. Rooms enable you to streamline complex agreements that include multiple parties, documents, and stages. ### Users *Users* are individuals who are invited to your company, or to a room. There are two types of users: * **Company users**: Your organization’s internal staff. Company users can be added to specific regions and offices. * **Room users**: Users who have been invited to a specific room, as well as the creator of the room. They can either be external or internal users. For example, you might invite an external real estate agent or buyer to a room. ### Roles A *role* defines a set of permissions for a user within a room. You can define custom roles for users that are either internal or external to your company, or use any of the preconfigured rules that come with Docusign Rooms. ### Room templates A *room template* holds room information and tasks for room participants. By specifying a template when you create a room, you can automatically import this data. You create room templates in the UI. ### Documents A *document* contains the content for a recipient to review or sign. Users can add documents to a room to share with others, if they have the appropriate permissions. ### Forms The *Docusign forms* feature enables you to add standard association forms to a room. Docusign Rooms provides access to forms from industry associations, such as the Mainstreet Organization of Realtors, via integrated form libraries. These libraries enable you to add these forms to your rooms directly by using the Rooms API. ### Room task lists A *room task list* holds a checklist of steps for a common transaction type. By specifying a task list when you create a room, you standardize the tasks that must be completed for the transaction. The assignees must check the items off the list before a room can be closed. #### Monitor API concepts ### Events Docusign Monitor tracks account activity across your organization. This activity is made up of *events* resulting from the actions taken by users, administrators, and APIs connected to your organization. ### Alerts When specific sets of events occur in your organization (typically events that indicate possible suspicious activity), Docusign Monitor can trigger an *alert*. When an alert is triggered, the activity that caused the alert is recorded in Monitor or your SIEM system, and the appropriate administrator or security operations team member is automatically notified. #### ID Evidence API concepts ### ID Verification (IDV) ID verification is a recipient authentication technology that verifies the identity of recipients based on government photo IDs (such as a driver’s license or passport) and electronic IDs. IDV verifies authenticity via visible security features, watermarks, and machine-readable barcodes. By default, no personal data is stored with IDV. The only data that is stored is the status of the ID verification, transaction number, and the name of the third-party ID verifier. ### Events A category of ID Evidence API call that handles logging state changes to an envelope’s recipient during the ID verification process. Selected text-based data, such as name, date of birth, and more are stored. ### Media A category of ID Evidence API call that retrieves 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. #### Notary API concepts ### Notary pool Each organization account that uses Notary API has a list of notaries that can be easily included to witness signing, called a notary pool. Your organization’s notary pool contains a set of users who can serve as a notary in a remote notary session initiated by your organization. ### Jurisdiction The Notary API tracks the jurisdiction state in which each notary session is completed. This enables you to record which requirements and processes were used for notarization. The API also supports (but does not enforce) jurisdictional requirements for these states, such as using digital signatures or varying notarial seals. ### Journaling Notaries are typically required to maintain a record of their official actions. The Notary API enables notaries to create journal entries for recording the actions of a notary session, which are saved and archived for your organization. ### Notary recipients Notaries are a specialized type of recipient that is new with the Notary API. To include a notary as a recipient for a document, include them just like you would any other recipient, but in a collection of type `notaries` (rather than `signers` or `carbonCopies`). A notary, together with 1–4 signers, is called a *notary group*. Currently, only a single notary group may be used for an envelope. #### Workflow Builder API concepts ### Workflows A workflow is an object that represents your end-to-end agreement workflow, including all pre- and post-signing [Steps](/docs/workflow-builder-api/workflow-builder101/steps). You can add and order steps as necessary for your workflow and add conditional logic to create branches within that workflow. ### Participants A participant is a person or entity involved in your agreement process. Participants will typically correspond to roles in the eSignature template you use for your signing step. ### Variables A workflow variable holds a piece of data used by the [Workflows](/docs/workflow-builder-api/workflow-builder101/workflows) [Steps](/docs/workflow-builder-api/workflow-builder101/steps). ### Steps Steps are the individual tasks executed in [Workflows](/docs/workflow-builder-api/workflow-builder101/workflows). Steps invoke functionality from Docusign modules such as eSignature and web forms or [Extensions](/extension-apps/extension-apps-101/concepts/extensions-and-extension-points) to call third-party platforms that an admin has authorized for your account, such as archiving a file to a cloud storage site or verifying bank account data. ### Branching rules A branching rule is a step that branches your workflow into one of two different paths, depending on the result of an if/else step. You can add a branching rule before or after any app step (such as identity verification or a web form), and then define the next actions to take if the branching rule is met or not. #### Agreement Manager API ### Agreement An agreement is a commitment between two or more parties that creates an obligation to perform (or not perform) a particular duty. Typically, agreements will contain a lot of other data, such as documents that describe the agreement being struck, parties who are involved in the agreement, dates defining the boundaries of the agreement, and many more. ### Document Documents are artifacts associated with agreements that typically define the terms of the agreement to be made. ### Parties A party is a person, entity, or group of entities who take part in an agreement. Typically, this means agreeing with other parties to do something together, although it can include other stakeholders. ### AI Insights Whenever you upload documents in Docusign Agreement Manager or complete a Docusign envelope, those documents are added to your account’s Agreement Manager repository. Agreement Manager then uses AI to analyze your documents and apply sets of Insights to them, automatically populating metadata about the agreement based on the contents of the documents. ### Category and type An agreement’s category object identifies the general purpose of the agreement, each of which is associated with a set of agreement types. For example, an agreement might have a category of Business services and a type of order form or a category of human resources and a type of offer letter. ### Provisions An agreement’s provisions object contains a list of properties that define the agreement parameters. #### Connected Fields API ### Connected fields A connected field is a field whose type is mapped to a corresponding object type in your system of record. The values for this type can be verified by data verification or connected fields extensions defined in your account. You can verify the inputs to your connected fields by creating a connected fields extension app and defining the verification logic on your system of record (for custom data models) or using a data verification extension app (for supported standard data models). ### Connected fields extension app A connected fields extension app is required to verify custom field values. See [Connected fields](/extension-apps/extension-apps-101/supported-extensions/connected-fields) for details. ### Custom data verification Custom data verification is a feature, provided by the Connected Fields API, that enables you to implement verification logic for custom fields, rather than only for fields that map directly to data verification extensions, such as [Bank account verification](/extension-apps/extension-app-reference/extension-contracts/bank-account-verification). ### Data verification extension app A data verification extension app is required to verify supported generic field values. See [Supported extensions](/extension-apps/extension-apps-101/supported-extensions) for details and a list of supported types. #### Workspaces API ### Workspaces A Docusign Workspace is a digital hub where you can bring the people, agreements, and information together that you need to execute a complex flow. ### Envelopes An *envelope* is a container for a Docusign agreement. 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 Envelopes are used to secure agreements in a workspace just as they are used generally through the eSignature API. ### Users *Users* are individuals who are invited to collaborate together in a workspace for an agreement. Users must be assigned a role as either a **manage** or **participate** user. ### Roles and permission levels A *role* defines a set of permissions that are applied to users in a workspace. ### Documents 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. ## Next steps * Learn more about the Docusign APIs: * See [eSignature REST API 101](/docs/esign-rest-api/esign101) and [eSignature concepts](/docs/esign-rest-api/esign101/concepts) for details on eSignature. * See [Web Forms API 101](/docs/web-forms-api/web-forms-101) and [Web Forms concepts](/docs/web-forms-api/web-forms-101/concepts) for details on Web Forms. * See [Click API 101](/docs/click-api/click101) and [Elastic signing concepts](/docs/click-api/click101/concepts) for details on Click. * See [Docusign Admin API 101](/docs/admin-api/admin101) and [Docusign Admin concepts](/docs/admin-api/admin101/concepts) for details on Docusign Admin. * See [Rooms API 101](/docs/rooms-api/rooms101) and [Rooms concepts](/docs/rooms-api/rooms101/concepts) for details on Rooms. * See Monitor [API 101](/docs/monitor-api/monitor101) for details on Monitor. * See ID Evidence [API 101](/docs/idevidence-api/idevidence101) for details on ID Evidence. * See Notary [API 101](/docs/notary-api/notary101) for details on Notary. * See [Workflow Builder API 101 overview](/docs/workflow-builder-api/workflow-builder101) for details on Maestro. * See [Agreement Manager API concepts](/docs/agreement-manager-api/concepts) for details on Navigator. * See [Connected fields concepts](/docs/connected-fields-api/concepts) for details on Connected Fields. * See [Workspaces API concepts](/docs/workspaces-api/workspaces101/concepts) for details on Workspaces. * Learn how to choose which [type of OAuth](/platform/auth) to use with your app.