Choosing an eSignature API: seven vendors compared on price, auth and webhooks

An eSignature API (also written e-signature API or electronic signature API) lets your code send a document for signature, follow its status and collect the signed file without anyone opening a dashboard. We compared seven vendors on what they publish. The lowest paid entry points we found were SignWell at $0.85 a document after 25 free a month, PandaDoc's API plan at $40 a month for 40 documents (its page names no billing cycle), and DocuSign's Starter developer plan at $50 a month billed annually.

Price is the easy part. What decides whether you still like an eSignature API a year in is the unit you pay for, how it authenticates, whether its webhooks are signed, and what a test send is worth. Those four questions knock out more vendors than any sticker price.

If you're building on Chaindoc, its REST API and webhooks come with the Business plan at €29 a month billed monthly. Every vendor fact below comes from that vendor's own page, with the date we read it.

Every eSignature API does the same four jobs: create a request, get it to the signer, report back, and hand over the signed file with its evidence. The differences sit in how each job is built and billed. These are the questions worth asking before anyone books a demo:

• Auth model. OAuth, API keys or both, and whether there's a read-only key you can ship to the browser.
• Embedded or emailed signing. Can signers sign inside your app, and is that on the plan you'll actually buy?
• Webhooks: are the payloads signed, is there a replay window, and can you see what was delivered?
• Templates. One call that renders a saved template and sends it spares you a lot of field-placement code.
• A sandbox that's free, kept apart from production, and honest about what its sends are worth.
• The pricing unit. Envelope, signature request, document, invite or signature, plus the billing cycle.
• Evidence export: the signed PDF, the audit trail and any proof, through the API rather than a dashboard.
• Branding on the signing page and in the emails, and which plan includes it.
• Signing order and rate limits, the two constraints teams tend to discover last.

The table puts each question next to what Chaindoc's own documentation answers, so you can hold every other vendor to the same list.

eSignature API pricing is more public than its reputation. Six of the seven vendors here publish an entry price. Adobe sells API access with its enterprise Acrobat Sign offering, and a public API price for it isn't on our record (2026-10-14). The rest fall into three models:

• Developer plans with a monthly allowance: DocuSign, Dropbox Sign and PandaDoc.
• A yearly invite bundle, or a per-invite licence: SignNow.
• Pay per document after a free monthly allowance: SignWell.

Chaindoc doesn't run a separate API price list. Its API sits inside the Business subscription, so the unit is the same signature allowance the web app uses.

DocuSign API pricing, plan by plan

DocuSign prices its developer plans apart from its eSignature seat plans. On its US developer pricing page, read on 14 October 2026, Starter costs $50 a month billed annually ($600 a year) or $75 billed monthly, starting at 40 envelopes a month. Intermediate is $300 a month billed annually, starting at 100 envelopes, and Advanced is $480 a month billed annually. Enhanced plans go through sales, with a five-user minimum. You don't need any of them to build, since the free developer account covers that. For the seat plans, see DocuSign's eSignature plans, explained.

Most eSignature API vendors use one of two auth models. API keys are simple: one secret, one header, full access to your own account. OAuth 2.0 takes more setup, but it lets your app act inside a customer's account with scoped, revocable access. That matters if you're building a product that other companies connect to their own e-signature accounts. Dropbox Sign's glossary draws the line cleanly: the API key for your own account, an OAuth token for someone else's.

Whatever the model, check three things. Is there a read-only key you can put in frontend code? Can you rotate keys without downtime? And does the sandbox share an account with production, or live apart from it?

Chaindoc's reference documents API keys, not OAuth: a read-only pk_ key for the browser and a full-access sk_ key for the server. That covers a single company's integration well. For a multi-tenant product where each customer brings their own signing account, an OAuth flow is the more natural fit, and DocuSign, Dropbox Sign, PandaDoc and SignNow each document one.

Embedded signing keeps the signer inside your product. Your backend opens a short-lived session, and the signing screen loads in an iframe on your page. Emailed signing sends a link to the vendor's hosted page instead. Logged-in users of your app usually get the first; counterparties who'll never create an account get the second. Most production integrations end up running both, and that's fine.

In Chaindoc, embeddedFlow: true on the signature request switches the embedded path on. Your server calls POST /embedded/sessions, passes the session ID to the Embed SDK, and the signer confirms a one-time code sent to their email before signing. A session lasts 10 minutes. Leave the flag off and the signer gets an emailed link to a hosted signing page instead.

Check which plan embedded signing sits on before you design an eSignature API integration around it. On DocuSign's US developer price table, read on 14 October 2026, embedded sending is ticked on every developer plan, while the embedded signing row is ticked only for the Enhanced plans that go through sales. Ask DocuSign which plan covers the exact flow you plan to ship. Dropbox Sign lists embedded signing among its API features; which of its plans includes it isn't on our record (2026-10-14).

In an eSignature API integration, a webhook your server silently drops is worse than none. Your system now believes it knows the contract's state, and it's wrong. Three checks separate a webhook design you can trust from one that wakes you at 2 a.m.

Verify the signature on every payload

Check the HMAC signature before you trust anything in the body, and compute it over the raw bytes, never over JSON you've parsed and re-serialized. Chaindoc's webhook documentation signs {timestamp}.{rawBody} with HMAC-SHA256 and sends the hex digest, prefixed v1=, in X-Chaindoc-Signature, with the timestamp in X-Chaindoc-Timestamp. Skip the check and anyone who learns your endpoint URL can post a fake "completed" event.

Reject replays and duplicates

The same event can arrive twice. Store the delivery ID (Chaindoc sends a UUID in X-Chaindoc-Delivery-Id) and ignore repeats. Chaindoc's Server SDK also rejects deliveries whose timestamp is more than five minutes away from your server's clock, which stops most replays cold.

Acknowledge fast, work later

Chaindoc counts a delivery as successful only if your endpoint returns a 2xx within 30 seconds. It retries a failed delivery a few times with backoff, then gives up, and after repeated failures across many events it disables delivery for that key. So return 200 straight away, push the event onto a queue, and do the slow work there. Webhooks are a Business-plan feature, set per API key in the dashboard, with logs under Settings → API Access → Webhook logs.

Put the same questions to every vendor on your shortlist: which header carries the signature, what exactly is signed, how long the retry window lasts, and where you can see what was sent. If a vendor can't tell you whether a webhook arrived, you'll be debugging blind. The event stream is also half of your evidence, so it's worth reading what a defensible audit trail holds before you decide what to store.

An eSignature API is only the transport. Legal effect comes from the law that governs the deal and from the signature level, not from whether the request left through a dashboard or a POST call.

In the United States, the ESIGN Act says that in a transaction in or affecting interstate or foreign commerce, a signature, contract or other record may not be denied legal effect, validity or enforceability solely because it's in electronic form (15 U.S.C. § 7001(a)). Most states have also adopted the Uniform Electronic Transactions Act, which gives electronic records and signatures the same standing under state law.

In the EU, Article 25 of the eIDAS Regulation stops a court from rejecting an electronic signature just because it's electronic, and gives the effect of a handwritten signature only to a qualified electronic signature (QES). Article 26 sets four tests for the advanced level (AES): the signature is uniquely linked to the signer, can identify them, is created with data under their sole control, and is linked to the signed data so that any later change is detectable.

Vendors sit on that ladder at different rungs, and the plan matters. DocuSign's developer table lists the simple level (SES) on Starter, Intermediate and Advanced, and SES, AES and QES on Enhanced. Chaindoc's documentation describes its own signatures as PAdES advanced electronic signatures with blockchain evidence. Chaindoc isn't a trust service provider and doesn't issue qualified certificates, so where a law demands a QES the certificate has to come from a qualified provider; our guide to qualified electronic signatures explains how that works. This is a summary of the statutes, not legal advice.

No eSignature API wins every row, and a comparison that pretended otherwise would be useless to you. On the evidence we read, this is where each vendor leads:

• DocuSign has the deepest developer tooling: SDKs in the common languages, downloadable Quickstart projects, Postman collections, and a free developer account that doesn't expire. Its Enhanced plans list AES and QES in the price table.
• Dropbox Sign publishes official SDKs in six languages (Python, Ruby, PHP, Java, NodeJS and C#), and its test-mode requests don't count against your quota.
• PandaDoc offers a free API tier with 60 documents a year and a full sandbox, with no card.
• SignNow pairs a free Dev Mode with unlimited test invites and 250 free invites to try in production.
• Adobe Acrobat Sign has a free Developer Edition with API access, plus a separate OEM and embedded partner programme for software vendors.
• SignWell has the lowest entry unit price we found: from $0.85 a document after 25 free a month.
• Chaindoc puts API keys and webhooks into one flat euro plan, adds a blockchain verification record to each published document version, and runs contracts with invoices through the same API. Its limits are real too: two TypeScript SDKs (any HTTP client works), invitations sent all at once through the API, no qualified certificates of its own, and a rate limit per key.

If DocuSign is the vendor you're replacing, our page on how Chaindoc compares with DocuSign goes plan by plan.

API keys and webhooks for the Chaindoc eSignature API come with the Business plan: €29 a month billed monthly or €278 billed yearly, with 100 signatures a month and €9 a month for each extra 10 (see Chaindoc's plans). On the Team plan, API access is available on request; Free and Personal don't include it.

The good fit is a product that needs signing, proof and payment in one flow. The same API creates documents, sends signature requests, renders templates, and runs contracts with invoices and payment setup. When you publish a document, the version hash the server computed at upload is written on chain, and each signer's proof is recorded once the request completes. GET /documents/versions/:versionId/verification returns the transaction hash and chain ID, which you'd keep with your own records. Identity checks are optional, per request: set isKycRequired: true when a deal needs one, and Business includes 10 a month.

The poor fit is a workflow that depends on signing order through the API. A request made through the API invites everyone at once; a set signing order is available through approval routes in the web app on Business. And if agent-driven workflows are on your roadmap, the public @chaindoc_io/mcp-server package wraps the same API; Chaindoc's MCP server for AI agents covers it.

Give each finalist the same five days.

1. 1.
   Authenticate and send a template-based request in the sandbox.
2. 2.
   Build the embedded path and the emailed path.
3. 3.
   Verify webhook signatures, replay a delivery, and take your endpoint down for an hour to see what the retries do.
4. 4.
   Export the signed file and the audit evidence through the API. It's the easiest step to skip, and the one that shows what you could hand a court.
5. 5.
   Price your real monthly volume in each vendor's unit, on the billing cycle you'd actually choose.

The eSignature API that gets through that week without a support ticket is usually the one to buy.