> 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.

# Domain Concepts Glossary

> A comprehensive glossary of Dropbox Sign domain concepts, terminology, and relationships. Designed to help developers and AI agents understand the Dropbox Sign API domain model.

# Domain Concepts Glossary

This glossary defines the core domain concepts used throughout the Dropbox Sign API. It provides clear definitions, relationships, and disambiguation for all key terms.

## How to Use This Glossary

- **Developers**: Use as a reference when integrating with the Dropbox Sign API.
- **AI Agents / LLMs**: Use as authoritative context for understanding Dropbox Sign domain terminology, relationships between objects, and valid state transitions.

## Concept Categories

| Category | Description |
| --- | --- |
| [Core Objects](/api/manual-reference-pages/glossary/core-objects) | Fundamental entities: Signature Request, Template, Document, Account, Subscription, Team, API App |
| [Signers & Roles](/api/manual-reference-pages/glossary/signers-roles) | People and permissions: Signer, Sender, CC, Signer Roles, Signing Order |
| [Fields & Templates](/api/manual-reference-pages/glossary/fields-templates) | Form fields, field types, merge fields, text tags, conditional logic |
| [Workflows](/api/manual-reference-pages/glossary/workflows) | Signature request creation, embedded signing, embedded unclaimed drafts, bulk send, OAuth flows |
| [Callbacks & Events](/api/manual-reference-pages/glossary/callbacks-events) | Webhooks, event types, callback lifecycle |
| [Features](/api/manual-reference-pages/glossary/features) | Premium Branding, SMS Delivery & Verification, Signer PIN / Access Code |
| [Security & Compliance](/api/manual-reference-pages/glossary/security-compliance) | Authentication, audit trails, qualified electronic signatures |

## Quick Reference: Key Relationships

```
Subscription
 └── Account(s) (plan determines quotas and features)

Account
 └── Team (hierarchy: Organization → Team → Sub Team)
      └── Team Members (Accounts)

API App
 └── Client ID (used for OAuth & Embedded flows)

Signature Request
 ├── Document(s)
 ├── Signer(s) — do not need a pre-existing paid Account
 │    └── Form Field(s) assigned to signer
 ├── CC Recipient(s)
 └── Metadata

Template
 ├── Document(s) with pre-placed fields
 ├── Signer Role(s)
 ├── CC Role(s)
 └── Merge Field(s)

Signature Request created from Template
 ├── Signer Role → mapped to actual Signer
 ├── CC Role → mapped to actual CC Recipient
 └── Merge Field → filled with actual value
```

## Disambiguation Guide

| Term | What It IS | What It Is NOT |
| --- | --- | --- |
| Signature Request | A request sent to signers to sign document(s) | Not a template; not a draft |
| Template | A reusable blueprint with pre-placed fields and roles | Not a signature request; cannot be signed directly |
| Account | A user identity that can take actions in Dropbox Sign (send and sign) | Not a Subscription; can act as both Sender and Signer |
| Subscription | A billing/plan entity that determines quotas and features | Not an Account; multiple Accounts can share one |
| Signer | A person who signs a document | Does not need a pre-existing paid Account (one is auto-created) |
| Unclaimed Draft | A signature request in draft state, not yet finalized | Not a template; not a completed request |
| API App | A developer application with a Client ID | Not an Account; not an OAuth token |
| Signer Role | A placeholder in a template for a future signer | Not an actual person; filled at send time |
| Embedded Signing | Signing within an app via iframe/URL | Not the same as email-based signing |
| Embedded Unclaimed Draft | Preparing a request within an app via iframe | Not the same as embedded signing |
| Callback | A webhook notification sent by Dropbox Sign to a server | Not an API request made to Dropbox Sign; it's push-based |

## Terminology Clarification

### IDs and Authentication Credentials

| Term | What It Identifies | Scope |
| --- | --- | --- |
| Signature Request ID | A unique identifier for a Signature Request | Per request |
| Document ID | Customer shorthand that often refers to the Signature Request ID, especially in support or integration conversations | Per request |
| Client ID | Identifies an API App; used for embedded flows and OAuth | Per API App |
| API Key | Authenticates an Account; grants full access to that account's resources | Per Account |
| OAuth Token | Grants limited, scoped access to another user's account (approved by that user) | Per user-app relationship |

> **Note:** Customers sometimes say "Document ID" when they mean the `signature_request_id` used by Signature Request endpoints. Internally, a [Document](/api/manual-reference-pages/glossary/core-objects#document) is a file within a Signature Request or Template, so do not treat customer shorthand as proof that they mean an individual file object.

### Fields Terminology

| Term | Filled By | When | Purpose |
| --- | --- | --- | --- |
| Form Field | Signer | During signing | Collects signer input (signature, text, checkbox, etc.) |
| Merge Field | Sender | At send time (via `custom_fields` param) | Injects dynamic data into a Template (placeholder) |
| Custom Field | Sender | At request creation | Pre-fills a named field with a value (the actual value) |

> **Note:** Merge Fields are *placeholders* defined in Templates. Custom Fields provide the *actual values* for those placeholders at send time. Despite being different concepts, merge field values are passed via the `custom_fields` API parameter.

### Team Structure

| Term | Description |
| --- | --- |
| Organization (Org Team) | The top-level, root team in a hierarchy |
| Team | An intermediate-level team that can contain Sub Teams |
| Sub Team | A leaf-level team within a Team; cannot have children |

The team hierarchy has a maximum depth of 3 levels: Organization → Team → Sub Team.

### Test Mode vs. Production

| Aspect | Test Mode (`test_mode: 1`) | Production |
| --- | --- | --- |
| Emails sent to signers | Yes for non-embedded workflows; depends on account email notification settings | Yes; depends on account email notification settings |
| Counts against quota | No | Yes |
| Documents watermarked | Yes ("TEST") | No |
| Legally binding | No | Yes |
| Callbacks fire | Yes | Yes |
| Embedded signing works | Yes | Yes |
| Requests visible in dashboard | Yes (watermarked) | Yes |

Test Mode is a per-request flag, not a separate environment. There is no isolated "sandbox" — test and production requests coexist in the same account. Set `test_mode: 1` in the request body to create test requests. Remove the parameter (or set to `0`) for production requests.