> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://developers.hellosign.com/llms.txt.
> For full documentation content, see https://developers.hellosign.com/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developers.hellosign.com/_mcp/server.

# Core Objects

> Definitions of fundamental Dropbox Sign domain objects including Signature Request, Template, Document, Account, Subscription, Team, and API App.

# Core Objects

The fundamental entities in the Dropbox Sign domain model.

---

## Signature Request

**Brief:** A formal request for one or more people to electronically sign one or more documents.

**Description:**
The central object in Dropbox Sign. It represents sending documents to signers for legally-binding electronic signatures and progresses through a defined lifecycle until all signers complete or the request is cancelled.

**Relationships:**
- Contains one or more **[Documents](#document)**
- Has one or more **[Signers](/api/manual-reference-pages/glossary/signers-roles#signer)**
- May have zero or more **[CC Recipients](/api/manual-reference-pages/glossary/signers-roles#cc-recipient)**
- May be created from a **[Template](#template)**
- Belongs to an **[Account](#account)** (the sender)
- Triggers **[Callback Events](/api/manual-reference-pages/glossary/callbacks-events#event-types)** on state changes

**Important Distinctions:**
- A Signature Request is not the same as an Unclaimed Draft. An Unclaimed Draft becomes a Signature Request once claimed.
- `is_complete` does not mean files are immediately downloadable. Wait for the `signature_request_downloadable` callback event before attempting to download.
- Signature Requests can enter an error state (`has_error`) during document processing.

**Related docs:** See the [Signature Request API reference](/api/signature-request) and [Non-Embedded Signing walkthrough](/docs/walkthroughs/non-embedded-signing).

---

## Template

**Brief:** A reusable document blueprint with pre-placed fields and defined signer roles.

**Description:**
Defines documents with pre-positioned form fields and placeholder signer roles. When creating a Signature Request from a Template, real signers are mapped to the defined roles and merge fields can be filled with dynamic data. Ideal for documents sent repeatedly (contracts, NDAs, onboarding forms).

**Relationships:**
- Contains one or more **[Documents](#document)** with pre-placed **[Form Fields](/api/manual-reference-pages/glossary/fields-templates#form-field)**
- Defines **[Signer Roles](/api/manual-reference-pages/glossary/signers-roles#signer-role)** (placeholders for actual signers)
- Defines **[CC Roles](/api/manual-reference-pages/glossary/signers-roles#cc-role)** (placeholders for CC recipients)
- May contain **[Merge Fields](/api/manual-reference-pages/glossary/fields-templates#merge-field)** for dynamic content
- Can be used to create **[Signature Requests](#signature-request)**
- Belongs to one or more **[Accounts](#account)**
- May belong to a **[Team](#team)**

**Important Distinctions:**
- Templates cannot be signed directly. A Signature Request must be created from a Template.
- Signer Roles are placeholders; they are mapped to actual Signers at request creation time.
- Field positions are fixed in templates and cannot be repositioned at send time.

**Related docs:** See the [Template API reference](/api/template) and [Templates walkthrough](/docs/walkthroughs/templates).

---

## Document

**Brief:** A file (PDF, Word, etc.) that is part of a Signature Request or Template.

**Description:**
An individual file within a Signature Request or Template. A single request/template can contain multiple documents. Documents are typically PDFs but can be uploaded in various formats (PDF, DOC, DOCX, etc.) which are converted to PDF for signing.

**Relationships:**
- Belongs to a **[Signature Request](#signature-request)** or **[Template](#template)**
- Contains zero or more **[Form Fields](/api/manual-reference-pages/glossary/fields-templates#form-field)**
- Has pages where fields are positioned

---

## Account

**Brief:** A registered user in Dropbox Sign identified by an email address.

**Description:**
Represents a registered user in Dropbox Sign. Accounts can send Signature Requests, create and manage Templates, and belong to Teams. Every API action is performed in the context of an Account. An Account can act as both a **Sender** (creating and owning Signature Requests) and a **Signer** (signing documents on requests created by others). An Account is not the same as a Subscription — multiple Accounts can exist under one Subscription, and an Account's capabilities depend on its associated Subscription plan.

**Note on Signers and Accounts:** When someone is added as a signer on a Signature Request, Dropbox Sign automatically creates a user account for them for the signing process. However, the signer does not need to have a pre-existing paid Dropbox Sign Account to be designated as a signer.

**Relationships:**
- May belong to a **[Team](#team)**
- Associated with a **[Subscription](#subscription)** (determines plan and quotas)
- Owns **[Signature Requests](#signature-request)** (as sender)
- Can be a **[Signer](/api/manual-reference-pages/glossary/signers-roles#signer)** on Signature Requests created by others
- Owns or has access to **[Templates](#template)**
- May own one or more **[API Apps](#api-app)**

**Important Distinctions:**
- Account ≠ Subscription. An Account is a user identity; a Subscription is the billing/plan entity.

---

## Subscription

**Brief:** The billing and plan entity that determines quotas, features, and capabilities for one or more Accounts.

**Description:**
A Subscription represents the commercial relationship with Dropbox Sign. It defines the plan level (Free, Essentials, Standard, Premium, etc.), monthly signature request quotas, available features (Premium Branding, templates, etc.), and team size limits. One Subscription may cover multiple Accounts (e.g., a team plan).

**Key Distinction:**
- **Account** = a user identity (who can log in and take actions)
- **Subscription** = a billing entity (what plan, quotas, and features are available)

An Account without a paid Subscription has limited capabilities (e.g., fewer signature requests per month, no access to premium features like templates or Premium Branding).

**Relationships:**
- Covers one or more **[Accounts](#account)**
- Determines available features and **[Quotas](/api/manual-reference-pages/glossary/security-compliance#quotas-rate-limits)**
- Defines the plan level

---

## Team

**Brief:** A group of Accounts that share templates, manage permissions, and collaborate on signature workflows.

**Description:**
Groups multiple Accounts together under shared management. Team members can share templates, and team admins can manage member permissions. Teams support a hierarchical structure with up to 3 levels of depth.

**Team Hierarchy:**
| Level | Name | Description |
| --- | --- | --- |
| Root | Organization (Org Team) | The top-level team in a hierarchy |
| Intermediate | Team | Can contain Sub Teams and has a parent Organization |
| Leaf | Sub Team | A child team within a Team; cannot have further children |

```
Organization (root)
 ├── Team A
 │    ├── Sub Team A1
 │    └── Sub Team A2
 └── Team B
      └── Sub Team B1
```

**Relationships:**
- Contains multiple **[Accounts](#account)** (members)
- Shares **[Templates](#template)** among members
- Has admin and member roles
- May have parent team (if not root/Organization)
- May have child teams (Sub Teams)

**Important Distinctions:**
- Maximum team hierarchy depth is 3 levels (Organization → Team → Sub Team).
- An Organization is simply the root team — it is not a separate entity type.

---

## API App

**Brief:** A developer application registered with Dropbox Sign, identified by a Client ID, used for embedded flows and OAuth.

**Description:**
Represents an application's integration with Dropbox Sign. Provides a Client ID used for embedded signing, embedded unclaimed drafts, and OAuth flows. Each API App can have its own branding (Premium Branding), callback URL, and OAuth configuration. An API App is required for any embedded functionality.

**Relationships:**
- Belongs to an **[Account](#account)** (the developer)
- Receives **[Callback Events](/api/manual-reference-pages/glossary/callbacks-events#event-types)**
- Used in **[Embedded Signing](/api/manual-reference-pages/glossary/workflows#embedded-signing)** and **[Embedded Unclaimed Draft](/api/manual-reference-pages/glossary/workflows#embedded-unclaimed-draft)** flows
- May have **[OAuth](/api/manual-reference-pages/glossary/workflows#oauth)** configuration for third-party access
- Can have **[Premium Branding](/api/manual-reference-pages/glossary/features#premium-branding)** customization

**Important Distinctions:**
- API Key (used for authentication) ≠ Client ID (used for embedded/OAuth app identification).
- Test mode uses the same Client ID but with `test_mode=1`.
- The API App's domain must be correctly configured for embedded signing to work.