Anvil vs Dropbox Sign: E-Signature API Comparison

Products

Industries

Resources

Developers

The short answer

Anvil and Dropbox Sign overlap on e-signatures and diverge almost everywhere else. Here is the honest version of who should pick which.

Choose Anvil if

Signing is the last step of a document problem, not the whole problem.
You fill PDFs with data at volume and would rather not open a signature request to do it.
You need to generate PDFs from HTML or Markdown as part of the same flow.
You want CSS-level control of the signing UI rather than a logo and a color.
You want the bill to track what your product does, not how many people work there: Anvil meters each fill, generation, and signature separately, so cost follows volume and adding teammates does not change your rate.

Choose Dropbox Sign if

You need e-signature and nothing else, and you want the simplest possible API for it.
Your team is already in the Dropbox ecosystem.
SMS-based signer authentication is a requirement.
Unclaimed drafts, where a signer prepares their own document, are part of your flow.
You would rather keep two clean budgets, a seat plan for the business and a separate volume-priced API plan, than meter every operation on one bill.

Feature parity: Anvil and Dropbox Sign

Where each platform lands on the capabilities developers actually ask about.

Yes: A first-class equivalent.
Partial: Reachable, but not directly. Expect to write some code.
No: No equivalent. You would build it yourself.

Capability	Anvil	Dropbox Sign
The core object	Three objects: a PDF Template for the document, an Etch e-sign packet for signatures, and a Workflow for data collection. Or no packet, if you only need a filled PDF.	A signature request.
Authentication	API key or OAuth 2.0. The key goes over HTTP Basic or Bearer auth, with separate development and production keys per organization, and no JWT handshake or account discovery before the first call. OAuth covers MCP clients and Enterprise multi-tenant apps.	An API key, plus a separate `client_id` for embedded signing.
Fill a PDF without a signature	Yes A standalone `/api/v1/fill` call. Send JSON, get a filled PDF back. No signing transaction required.	Partial Filling happens through a signature request with merge fields. There is no standalone fill endpoint.
Generate a PDF from HTML or Markdown	Yes Native. POST HTML/CSS or Markdown to `/api/v1/generate-pdf` and get a PDF.	No No native generation. You bring your own PDF.
Embedded signing in your own app	Yes `signerType: 'embedded'` plus `generateEtchSignURL`, rendered with the open-source `AnvilEmbedFrame` component.	Yes `client_id` plus `getSignUrl`, rendered with the hellosign-embedded library. Mature and well documented, and gated to their Premium API tier.
Embedded sending, your users prepare documents	Yes `generateEmbedURL` embeds the full packet builder, and the URL it returns is one time use. Your users add documents, connect signers, and send, and they do not need Anvil accounts of their own: your app authenticates them.	Yes Embedded requests and unclaimed drafts let signers or senders prepare documents in your app.
White label the signing UI	Yes CSS themes you author and host, applied to the whole signing experience. Included in Product Pack.	Partial Branding options on higher API plans: logo, colors, and email customization.
Signing order and parallel signers	Yes `routingOrder` on each signer. Equal values sign in parallel.	Yes Signing order on each signer, plus signing groups where any member may sign a step.
Structured data collection before signing	Yes Two surfaces. Anvil Workflows for webforms, conditional logic, and multi-party collection before signing, and Interactive Signing for fields the signer completes inside the signing page itself.	Partial Custom fields on a template. No separate webform or conditional-logic product.
Built-in signer identity verification	Partial Email signers get the link at the address you name, so signing needs access to that mailbox. No SMS, phone, or knowledge-based ID check. For embedded signers you verify the person in your own app, then generate a short-lived sign URL.	Yes SMS-based signer authentication is built in.
Bulk send from one template	Partial No batch endpoint. You loop `createEtchPacket`, and the official clients handle rate limiting and retries.	Yes BulkSendJob sends one template to many recipients.
Send on behalf of customer accounts (multi-tenant)	Yes Register an Anvil OAuth app for each tenant to authorize, or give each tenant a child organization with its own API key. Both are Enterprise features.	Yes OAuth lets your app act on behalf of customer accounts.
Automatic template field detection	Yes Upload a flat PDF and Document AI finds, labels, and types the fields for you.	Partial Drag-and-drop tagging in the template editor, or text tags embedded in the source document.
MCP server for AI agents	Yes A hosted server at `mcp.useanvil.com` over streamable HTTP, authenticated with OAuth sign-in rather than an API key. Agents can fill PDFs, generate PDFs, and run GraphQL queries and mutations. Anvil MCP docs	No No official server. Community-built ones exist, maintained outside Dropbox.
Rate limits	40 requests/second 144,000 calls/hour Paid production keys. Free and pay-as-you-go keys run at 4/second.	1.6 requests/second 6,000 calls/hour 100 requests/minute for standard calls, 25/minute for higher-tier ones, and 10/minute in test mode. Higher volumes are negotiated.
Official SDKs	Clients for JavaScript, TypeScript, Python, and C#/.NET. Go, Java, PHP, and Ruby are listed as coming soon. Everything else is plain HTTP against a documented API.	Six official SDKs, all generated from their OpenAPI spec: Node.js, Python, Ruby, PHP, Java, and C#/.NET.

How we chose what to compare

Every one of our comparison pages asks the same 16 questions, in the same order, and scores 12 of them on both platforms. The list does not change from one competitor to the next, so no platform gets an easier scorecard than another.

Where the list came from. These are the capabilities our migration plugins had to map when porting real integrations onto Anvil. They are the questions that came up in practice, not a set picked to flatter us.
Anvil's answers are written once. The Anvil side of every capability row is shared across all of these pages, so it cannot be reworded to read better beside a particular competitor. Only the opening row, which sets out how each product models a document, is written per comparison.
4 of the 16 carry no verdict. The core object, Authentication, Rate limits, and Official SDKs are architectural differences rather than parity questions, so they show no badge. That leaves the 12 scored capabilities the counts at the top of this page are drawn from.
Both sides come from published docs. Claims about Dropbox Sign are drawn from Dropbox Sign's own API documentation, and claims about Anvil from ours. Where the two disagree, their documentation wins.

Which one fits your situation

Concrete cases, and the honest answer for each. Anvil and Dropbox Sign both win some of these outright.

Use Anvil
Signing is the last step of a document problem, not the whole problem
Anvil covers generating and filling the document too. Dropbox Sign starts at the signature.
Use Anvil
You fill PDFs at volume and would rather not open a signature request to do it
Anvil meters a fill as a fill. On Dropbox Sign filling runs through a signature request.
Use Anvil
You need to generate PDFs from HTML or Markdown as part of the flow
Anvil generates natively. Dropbox Sign expects you to bring the PDF.
Use Anvil
You want CSS-level control of the signing UI, not a logo and a color
Anvil themes the whole signing experience with CSS you author.
Use Dropbox Sign
You need e-signature and nothing else, as simply as possible
Dropbox Sign does this and little else, which keeps the integration small. A broader platform is surface area you would not use.
Use Dropbox Sign
You need SMS authentication before a signer can open the document
Built into Dropbox Sign. On Anvil you would gate the sign URL behind your own OTP flow.
Use Dropbox Sign
You want signers to prepare and claim their own document
Unclaimed drafts have no direct Anvil equivalent.
Use Dropbox Sign
Your documents already live in Dropbox and that integration does real work
That is a legitimate reason to stay where you are.

What Anvil does that is genuinely different

These are the four things that change how you build, not the rows where Anvil and Dropbox Sign both say yes.

Filling and signing are separate calls

Anvil treats "put data in a PDF" and "get this signed" as two operations. You can fill a thousand PDFs a day without opening a single signature transaction, and only pay the signing rate when a signature is actually involved.

PDF Filling API

One platform for the whole document

Generate the PDF from HTML or Markdown, fill it from your JSON, collect the data that feeds it through a webform, then send it for signature. One vendor, one API key, one bill.

Workflows

Document AI does the template setup

Upload a flat PDF and Anvil finds the fields, labels them, and makes the document fillable. Template setup stops being a manual drag-and-drop afternoon.

Document AI

Built for the agent era

Anvil ships an MCP server at mcp.useanvil.com, so coding agents can create templates, fill PDFs, and send packets directly. The migration plugins below run on it.

Anvil MCP

Where Dropbox Sign is the better answer

No platform wins every row. These are the cases where we would tell you to stay put, or at least to check carefully before you commit.

Pure e-signature simplicity

If all you will ever need is "send this PDF to these people for signature", Dropbox Sign API is scoped to exactly that, and a narrow API is easier to integrate and easier to reason about. Anvil would be surface area you do not use.

Unclaimed drafts

Letting a signer prepare and claim their own document has no direct Anvil equivalent. You would model it with a Cast plus an embedded packet builder.

SMS authentication

Built into Dropbox Sign. On Anvil you would gate the sign URL behind your own OTP flow before generating it.

Dropbox ecosystem

If documents already live in Dropbox and that integration is doing real work for your team, that is a legitimate reason to stay.

How the two charge

Anvil and Dropbox Sign bill on different axes, and that decides more than the rates do. Here is the shape of each model, so you can work out which one your volumes favor.

Anvil

Usage-based, with optional feature packs

You pay for what you call: PDF fills, PDF generations, e-sign packets, and workflow submissions are each metered per unit.
Cost tracks volume, not headcount. Adding teammates does not change the rate you pay per document.
A free plan covers building and testing. Two paid packs add Document AI over API, and white labeling with advanced signing.
Bulk pre-purchase discounts apply at higher volumes.

See Anvil plans and rates

Dropbox Sign

Seats for the business, a separate API plan sized by monthly volume

The API is sold on its own, in tiers you pick by expected monthly signature requests: 50, 100, 250, 500, or 750 and up. Their own line is that the more signatures you request per month, the less each request costs.
You buy that tier up front rather than metering, so the gap between your real volume and the tier you bought is money already spent.
Embedded signing and premium branding sit on the Premium tier, which is a sales conversation rather than a published price. SMS and electronic ID are paid add-ons above that.
Test mode is free, so building and testing costs nothing.

See Dropbox Sign plans and rates

We compare how each platform charges rather than reprinting rates, because plan structures change and a stale number helps nobody. Both links above go to the source of truth. Last reviewed September 2026.

Already decided to move off Dropbox Sign?

The plugin swaps hellosign-embedded for AnvilEmbedFrame and rewrites your callbacks as Anvil webhook actions.

See the Dropbox Sign migration guide for the terminology map, the before-and-after code, the migration steps, and the open-source plugin that runs them.

Compare Anvil with something else

Anvil vs Docusign Anvil vs PandaDoc Anvil vs Adobe Sign Anvil vs SignNow Anvil vs Xodo Sign Anvil vs BoldSign

Get a demo
(from a real person)

Schedule some time on our calendar to talk through your specific use case and see which Anvil products can help.

Want to try Anvil first?

These customers get it:

Want to try Anvil first?

Secure, compliant, reliable

Anvil uses digital certificates, specifically the industry-standard Public Key Infrastructure (PKI) framework, for identity verification in document signing. This involves creating a pair of certificates – public and private. Read more

Secure, compliant, reliable

Marketing Mode

Anvil vs. Dropbox Sign

The short answer

Choose Anvil if

Choose Dropbox Sign if

Feature parity: Anvil and Dropbox Sign

How we chose what to compare

Which one fits your situation

What Anvil does that is genuinely different

Filling and signing are separate calls

One platform for the whole document

Document AI does the template setup

Built for the agent era

Where Dropbox Sign is the better answer

Pure e-signature simplicity

Unclaimed drafts

SMS authentication

Dropbox ecosystem

How the two charge

Anvil

Dropbox Sign

Already decided to move off Dropbox Sign?

Compare Anvil with something else

Get a demo(from a real person)

Secure, compliant, reliable

Secure, compliant, reliable

Get a demo
(from a real person)