The fundamental entities in the Dropbox Sign domain model.
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:
Important Distinctions:
is_complete does not mean files are immediately downloadable. Wait for the signature_request_downloadable callback event before attempting to download.has_error) during document processing.Related docs: See the Signature Request API reference and Non-Embedded Signing walkthrough.
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:
Important Distinctions:
Related docs: See the Template API reference and Templates walkthrough.
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:
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:
Important Distinctions:
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:
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:
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:
Relationships:
Important Distinctions:
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:
Important Distinctions:
test_mode=1.