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

# Security & Compliance

> Authentication methods, audit trails, and qualified electronic signatures in the Dropbox Sign API.

# Security & Compliance

Authentication, security features, and compliance-related concepts in Dropbox Sign.

---

## Authentication Methods

**Brief:** The ways identity is proven when making API requests to Dropbox Sign.

### API Key Authentication

An API key identifies an account and grants full access to that account's Dropbox Sign resources.

**Usage:**
```
Authorization: Basic {base64(API_KEY:)}
```

Note the colon after the API key with no password — this is HTTP Basic Auth with the API key as the username.

**Key Facts:**
- Up to 4 API keys per account
- Full access to the account's resources
- Should be kept secret (server-side only)
- Keys can be regenerated or deleted
- Do NOT use in client-side code

### OAuth Token Authentication

OAuth tokens allow an application to act on behalf of other users who have granted permission.

**Usage:**
```
Authorization: Bearer {access_token}
```

**Key Facts:**
- Access tokens expire (use refresh tokens to renew)
- Scoped — limited to permissions the user granted
- One token per user-app relationship
- See [Workflows > OAuth](/api/manual-reference-pages/glossary/workflows#oauth) for the full flow

### When to Use Which:

| Scenario | Method |
| --- | --- |
| Application sends requests from its own account | API Key |
| Application sends on behalf of other users | OAuth |
| Server-side integration | API Key or OAuth |
| Client-side code | Neither (use server as proxy) |

**Related docs:** See the [API authentication reference](/api/api-reference-authentication) for API key and OAuth setup.

---

## Audit Trail

**Brief:** A tamper-evident record of all actions taken on a Signature Request, proving who did what and when.

**Description:**
Every Signature Request generates an Audit Trail — a detailed log of all events from creation to completion. It is embedded in the final PDF as additional pages and provides legal evidence of the signing process. Automatically generated and cannot be modified.

**What the Audit Trail Records:**
| Event | Details Captured |
| --- | --- |
| Request created | Timestamp, sender identity |
| Document uploaded | Document hash (SHA-256) |
| Request sent | Timestamp, recipient emails |
| Signer viewed | Timestamp, IP address, user agent |
| Signer signed | Timestamp, IP address, signature image |
| Signer authenticated | PIN or SMS verification timestamp |
| Signer delegated | Delegation to another signer |
| Signer email/name updated | Change of signer details |
| Request completed | Final timestamp, document hash |
| Request declined | Timestamp, reason (if provided) |
| Request cancelled | Timestamp, who cancelled |
| Request expired | Expiration timestamp |
| Request edited and resent | Edit & resend actions |
| Signer removed | Signer removal via edit |
| QES sent/declined | Qualified eSignature flow events |

**Key Facts:**
- Tamper-evident: any modification invalidates the audit trail
- Merged into the final pages of the completed PDF document
- Includes SHA-256 document hash proving the document wasn't altered after signing
- Captures signer IP addresses at each interaction

---

## Qualified Electronic Signatures (QES)

**Brief:** A higher standard of electronic signature meeting EU eIDAS regulation requirements, providing the legal equivalent of a handwritten signature in Europe.

**How QES Differs from Standard E-Signatures:**
| Aspect | Standard E-Signature | QES |
| --- | --- | --- |
| Legal standing | Valid but may be challenged | Presumed valid (highest legal weight) |
| Identity verification | Email-based | Government ID + video/in-person verification |
| Certificate | Not required | Qualified certificate from TSP |
| EU-wide recognition | Varies by country | Recognized in all EU states |
| Use cases | General business | Regulated industries, high-value contracts |

---

## Quotas & Rate Limits [#quotas-rate-limits]

**Brief:** Limits on signature requests and API calls based on the Subscription plan.

**Description:**
Dropbox Sign enforces quotas on signature requests and rate limits on API calls. These are determined by the Subscription plan.

**Quota Types:**
| Quota | Description |
| --- | --- |
| Signature Request quota | Monthly limit on signature requests (varies by plan) |
| Template quota | Maximum number of templates |
| API rate limit | Maximum API calls per minute/hour |

**Key Behaviors:**
- Quotas reset monthly
- Test mode requests do NOT count against quotas
- Rate limits return HTTP 429 with retry information
- Exceeded quotas return HTTP 402

**Handling Rate Limits:**
1. Check the `X-Ratelimit-Limit` and `X-Ratelimit-Remaining` response headers
2. If a 429 response is received, wait and retry (respect the `Retry-After` header)
3. Implement exponential backoff for retries

**Important Distinctions:**
- Test mode requests do NOT count against quotas.
- Rate limit responses (HTTP 429) include retry information — implement exponential backoff.
- Exceeded quotas return HTTP 402.

**Related docs:** See [Warnings and Errors](/api/manual-reference-pages/warnings-and-errors) for error responses.