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

# Signers & Roles

> Understanding signers, senders, CC recipients, signer roles, and signing order in the Dropbox Sign API.

# Signers & Roles

People and permission concepts in Dropbox Sign: who signs, who receives copies, and how roles work in templates.

---

## Signer

**Brief:** A person who is required to sign, initial, or fill out fields on a Signature Request.

**Description:**
An individual designated to complete form fields (signature, initials, text, etc.) on a Signature Request. Each signer is identified by email address and name. A signer does not need to have a pre-existing paid Dropbox Sign Account — anyone with an email address can be designated as a signer. Dropbox Sign automatically creates a user account for the signer during the signing process.

An Account holder can also be a Signer on requests created by other Accounts.

**Relationships:**
- Belongs to a **[Signature Request](/api/manual-reference-pages/glossary/core-objects#signature-request)**
- Is assigned **[Form Fields](/api/manual-reference-pages/glossary/fields-templates#form-field)** to complete
- Maps to a **[Signer Role](#signer-role)** when request is created from a template
- Does not require a pre-existing paid **[Account](/api/manual-reference-pages/glossary/core-objects#account)** — Dropbox Sign creates one automatically for signing

**Important Distinctions:**
- Each signer on a request must have a unique email address.
- When creating a request from a template, the `role` field must be specified to map the signer to the template's pre-placed fields.
- The signer's `order` (signing sequence) is different from the document's `index` (document sequence).

---

## Sender

**Brief:** The Account that initiates and owns a Signature Request.

**Description:**
The Account that creates and sends a Signature Request. The sender can cancel the request, send reminders to signers, and download completed documents. The sender is not a signer by default but can be added as one.

**Relationships:**
- Is an **[Account](/api/manual-reference-pages/glossary/core-objects#account)**
- Creates and owns **[Signature Requests](/api/manual-reference-pages/glossary/core-objects#signature-request)**
- Can send reminders to **[Signers](#signer)**
- Receives **[Callback Events](/api/manual-reference-pages/glossary/callbacks-events#event-types)** for their requests
- Can optionally also be a **[Signer](#signer)** on the same request

---

## CC Recipient

**Brief:** A person who receives a copy of the completed documents but does not sign.

**Description:**
A CC (Carbon Copy) Recipient receives a copy of the final signed documents once the Signature Request is complete. CC Recipients do not have any fields to fill out and cannot sign.

**Relationships:**
- Belongs to a **[Signature Request](/api/manual-reference-pages/glossary/core-objects#signature-request)**
- Maps to a **[CC Role](#cc-role)** when using templates
- Receives completed documents (not signing notifications)

---

## Signer Role

**Brief:** A named placeholder in a Template that represents a future signer to be specified at send time.

**Description:**
A placeholder defined in a Template. Since the actual signers are unknown at template creation time, roles like "Client", "Contractor", "Witness" are defined instead. Form fields are assigned to these roles. When creating a Signature Request from the Template, each role is mapped to an actual person.

**Example Mapping:**
```
Template Signer Roles:
  - "Client" (order: 0)
  - "Contractor" (order: 1)

At send time:
  signers[0] = { role: "Client", email: "client@example.com", name: "Jane Doe" }
  signers[1] = { role: "Contractor", email: "contractor@example.com", name: "John Smith" }
```

**Relationships:**
- Defined in a **[Template](/api/manual-reference-pages/glossary/core-objects#template)**
- Has **[Form Fields](/api/manual-reference-pages/glossary/fields-templates#form-field)** assigned to it
- Mapped to an actual **[Signer](#signer)** at request creation time

**Important Distinctions:**
- The role is a placeholder label; the actual signer name is provided when creating the request.
- Role matching is exact and case-sensitive — the role name in the request must match the template's defined role name exactly.

---

## CC Role

**Brief:** A named placeholder in a Template that represents a future CC recipient to be specified at send time.

**Description:**
Similar to Signer Roles, CC Roles are placeholders in Templates for CC Recipients. They define who should receive copies but are not assigned any fields.

---

## Signing Order

**Brief:** The sequential order in which signers must complete their signatures.

**Description:**
Signing Order (also called "ordered signing") enforces that signers must sign in a specific sequence. When enabled, only the currently active signer(s) can sign. The next signer becomes active only after the previous one completes. When signing order is disabled, all signers can sign simultaneously.

**How It Works:**
1. Signer with `order: 0` can sign first
2. Once they complete, signer with `order: 1` becomes active
3. Process continues until all signers complete
4. Signers with the same `order` value can sign simultaneously

**Key Behaviors:**
- Only the currently active signer(s) can sign at any given time
- If a signer declines, subsequent signers are never activated
- In embedded signing, a signing URL can only be generated for the currently-active signer

**Important Distinctions:**
- When using signing order, explicit `order` values must be assigned to each signer.