Dropbox Sign
DOCS & KNOWLEDGE · FILES & DOCS
Signature requests, templates and signing links sent from their own account.
Connecting Dropbox Sign in practice
"Applications using certain features of the Dropbox Sign API are subject to an approval process before they can be used in production", and an OAuth implementation has to go through Support Assisted Approval rather than self-publish. API keys never expire and cannot be scoped at all; the hourly rate limit is never published, only returned in X-RateLimit-Limit.
Scopes that draw scrutiny
account_accessUser-charged OAuth scope granting access to the authorizing user’s Dropbox Sign account itself rather than to one request.signature_request_accessReads and acts on the user’s signature requests, so it reaches agreements the app did not create.template_accessReads and modifies the user’s templates, which are the definitions other integrations send from.team_accessReaches the user’s team rather than only the user, so one person’s consent exposes colleagues’ data.api_app_accessManages the user’s API apps, meaning it can read or alter the credentials of other integrations.request_signatureApp-owner charged rather than user charged, so every signature request sent under it bills the integration rather than the customer.
Rate limits
- X-RateLimit-Limit is documented as "The maximum number of requests per hour that you can make", with X-RateLimit-Remaining and X-Ratelimit-Reset (a Unix time). Dropbox Sign does not publish the figure itself.
Who has to approve
Not a tenant-admin gate but an app gate: embedded eSignature workflows must pass Dropbox Sign’s app approval before production use, while non-embedded workflows are exempt. There are two submission paths — Self Publish for eligible apps and Support Assisted Approval, which is required for OAuth implementations and is reviewed directly by API support.
Worth knowing
- Authentication is HTTP Basic with the API key as the username and a blank password, so the credential is base64 rather than a bearer token. Up to 4 keys per account, and Dropbox Sign says "We recommend rotating API keys at least once a year".
- API keys are long-lived with no expiration and no scope control; only OAuth access tokens expire (after one hour) and only they can be narrowed by scope.
- There is no separate test credential: "Any valid API key can be used for testing by including the test_mode parameter", so the same key touches sandbox and production and the only difference is one request field.
- Going live means removing test_mode from backend requests after approval, which is a code change in the caller rather than a setting flipped on the account.
Checked against Dropbox Sign API authentication (2026-09-29), Dropbox Sign OAuth overview (2026-09-29), Dropbox Sign app approval (2026-09-29), Dropbox Sign OpenAPI specification (2026-09-29)
What an agent can do
Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.
Often connected alongside
Put Dropbox Sign behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.