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

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:

Check the X-Ratelimit-Limit and X-Ratelimit-Remaining response headers
If a 429 response is received, wait and retry (respect the Retry-After header)
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 for error responses.