Dropbox Sign web plan or API plan for embedded signing?

Choose a Dropbox Sign API plan if customers must sign inside your application. Choose a web subscription when your people send from the Dropbox Sign app. For production, Dropbox’s workflow table sets Standard API as the minimum for embedded signing or requesting and Premium API for embedded templates. Essentials API covers non-embedded signing or requesting. Dropbox Sign API plan guide

The first purchasing question is where each action happens. A staff member opening the Sign app to send a document has a web workflow. A customer signing within your product has an embedded workflow, even if an employee started the transaction. If someone prepares a request inside the product, classify that action as embedded requesting too. Map signing, requesting, and template work separately before selecting a tier.

Workflow you intend to launch	Plan decision	Failure condition to catch
Staff send from the Sign app; customers need no in-product signing screen	Evaluate a web subscription	The requirement changes to signing inside the product, but the purchase remains a web subscription.
Your application uses non-embedded signing or requesting	Evaluate Essentials API as the published minimum	An embedded step enters the design without a tier review.
Customers sign in the product, or staff prepare requests there	Evaluate Standard API as the published minimum	The team buys Essentials API after a successful test-mode prototype.
Product users create or edit embedded templates	Evaluate Premium API as the published minimum	Templates enter a Standard API rollout without a plan change.

The API minimums come from Dropbox’s workflow table.

Consider a team planning 30 signature requests a month. One operations manager starts each agreement, two customers sign each request, and two engineers maintain the application. If the manager sends through the Sign app and customers sign outside the product, compare web subscriptions against that staff workflow. If those customers must sign within the product, the planned request count stays the same, but embedded signing requires Standard API for production. If the manager must prepare requests inside the product, embedded requesting points to the same minimum. If product users must create or edit templates there, the published minimum becomes Premium API. These roles and counts are planning inputs, not Dropbox entitlements. Official workflow tiers

Do not carry a web plan’s “unlimited” request statement into an API budget. Dropbox distinguishes unlimited signing or requesting on paid web plans from API limits expressed in signature requests. API subscriptions are metered by monthly request volume, so estimate requests from expected transactions and obtain a current quote for the relevant tier. In the example, two signers on a request do not turn a web allowance into an API allowance. Dropbox’s plan-limit explanation · API pricing

A prototype can give the wrong purchasing signal. Dropbox says test_mode can exercise endpoints and most features even on a free account; production still needs the tier for the chosen workflow. Before rollout, identify the production account, the people permitted to initiate or manage requests, and the product users who will encounter each embedded step. Hold launch if those permissions, the subscription tier, or the intended workflow remain unconfirmed. Dropbox’s API plan guide

Pre-purchase validation

• Map each signing, requesting, and template action to the Sign app, a non-embedded flow, or an embedded product screen.
• Estimate monthly API signature requests and check the current quote for the required tier; compare web terms separately.
• Pilot callbacks, signer identity, completed-document download, and storage of downloaded files in the product.
• Confirm the production account’s tier and each participating role’s permissions before setting a launch date.
• Recheck the plan if the rollout adds an embedded action or the subscription changes.