Last reviewed September 2026. Xodo Sign features and pricing change, so check their own pages before you decide.
Anvil and Xodo Sign overlap on e-signatures and diverge almost everywhere else. Here is the honest version of who should pick which.
Where each platform lands on the capabilities developers actually ask about.
| Capability | Anvil | Xodo 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 document, identified by a document_hash, optionally created from a template. |
| 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 access_key plus a business_id, both passed as query parameters on every REST call. |
| 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 Field values and template merge fields on a document. Not a 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 | YessignerType: 'embedded' plus generateEtchSignURL, rendered with the open-source AnvilEmbedFrame component. | Yes Set embedded_signing on the document and use the returned embedded_signing_url. |
| Embedded sending, your users prepare documents | YesgenerateEmbedURL 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. | Partial Document preparation happens in the Xodo Sign editor rather than inside 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 controls in the dashboard on higher tiers. |
| Signing order and parallel signers | YesroutingOrder on each signer. Equal values sign in parallel. | Yes order on each signer plus use_signer_order on the document. |
| 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 Document form fields only. 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 A signer PIN, or SMS authentication that texts a code before the document unlocks. The two cannot be combined on the same signer. |
| Bulk send from one template | Partial No batch endpoint. You loop createEtchPacket, and the official clients handle rate limiting and retries. | Partial Sending to many recipients is done per document rather than as a batch job. |
| 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. | Partial Several businesses can sit under one account via business_id, though it is not OAuth-on-behalf. |
| Automatic template field detection | Yes Upload a flat PDF and Document AI finds, labels, and types the fields for you. | Partial Fields are placed by hand in the template editor. |
| MCP server for AI agents | Yes A hosted server at Anvil MCP docsmcp.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. | No No official server. Reachable only through third-party automation connectors. |
| Rate limits |
Paid production keys. Free and pay-as-you-go keys run at 4/second. | No published rate limits. The API documentation does not state a ceiling, so plan for one you cannot see. |
| 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. | Three official clients, still published under the eversign name: PHP, Node.js, and Python. |
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.
Concrete cases, and the honest answer for each. Anvil and Xodo Sign both win some of these outright.
Filling PDFs with data is a first-class part of your product
Anvil has a standalone fill endpoint. On Xodo Sign filling runs through a document.
You want to generate documents from HTML or Markdown in the same API
Anvil generates natively. Xodo Sign expects you to bring the PDF.
You want CSS-level control of the signing experience inside your app
Anvil themes the whole signing UI. Xodo Sign offers dashboard branding.
You would rather not thread an access_key and a business_id through every request
Anvil is one key on one host, with no business selection call.
Low per-seat cost is the deciding factor
Xodo Sign competes on price, and at modest volume from a small team it may simply be cheaper.
You need PIN or SMS verification before signing
Built into their signing flow. Anvil has none.
You already use Apryse PDF SDK or WebViewer
Keeping signing with the same vendor has real procurement value.
You run several separate businesses under one login
The business_id model supports that directly. On Anvil it means separate organizations and keys.
These are the four things that change how you build, not the rows where Anvil and Xodo Sign both say yes.
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 APIGenerate 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.
WorkflowsUpload 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 AIAnvil 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 MCPNo 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.
Xodo Sign competes on price. If you send a modest number of documents from a small team, their plans may simply be cheaper. Run your own numbers.
Built into the signing flow. On Anvil you would verify the signer yourself before generating the sign URL.
If you already use Apryse PDF SDK or WebViewer, keeping signing with the same vendor has real procurement value.
The business_id model that adds friction to every call is also a feature: several separate businesses under one login. On Anvil that means separate organizations and keys.
Anvil and Xodo 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.
Usage-based, with optional feature packs
Unlimited documents on a seat, a separate API plan metered by document
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.
The plugin drops the business_id threading and maps eversign signer roles and positioned fields onto Anvil.
See the Xodo Sign migration guide for the terminology map, the before-and-after code, the migration steps, and the open-source plugin that runs them.
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