The best eSignature API depends on what your app does either side of the signature: embedded signing inside your own screens, document generation, a wider agreement workflow, or an open source route you host yourself. Pick that type first, then test two APIs of that type against a real document before you commit.
Three questions to answer before you open any docs
Every API on this page will put a signature on a PDF, so signing alone won't separate them. What separates them is everything around it: where the document comes from, whose name the signer sees, how your app hears that the job is finished, and where the signed file and its audit trail are kept.
Write down three short answers. What creates the document: a template, your own PDF generator or a file the user uploads? Should the signer ever see another company's name on screen? And what must your app do the moment the last signature lands: unlock an account, take a payment, file a record? Those answers sort the market into five rough shapes.
Five shapes of signing API
Wider agreement suites. Docusign and Adobe live here. Docusign lists separate Click, Rooms, Notary and Web Forms APIs next to its REST and SOAP signing APIs, and Adobe offers an OEM and embedded partner route for platforms. If your customers already run their agreements through one of these names, they'll expect your product to plug straight in, and this is where you start.
Embedded signing inside your own interface. airSlate SignNow, BoldSign, Dropbox Sign and Zoho Sign all describe signing you build into your own screens, with branding and webhooks among their talking points. It's the busiest group and the one most product teams end up choosing from, so a side-by-side sandbox test pays off most here.
Documents first, signature second. If your app fills a contract from customer data before anyone signs, PandaDoc leans that way, describing generation, sending, signing and management through a single API. It can spare you writing a document builder alongside the signing flow, and the builder is usually the bigger of the two jobs.
Open source you can host yourself. Documenso and DocuSeal both publish their code and offer a self-hosted route. A client contract or a regulator that says documents can't leave your infrastructure settles the question for you.
Signing from a terminal or an AI chat. SignWell lists a CLI and an MCP server, which means an AI assistant can send a document for signature when someone asks it to. Worth a look if your team already works that way; otherwise it's a nice extra rather than a reason to choose.
Ten APIs for the shortlist
No ranking here, because the right API depends on your shape. Match each name to the one you picked above and your two test candidates fall out.
Adobe Acrobat Sign API
Adobe's signing API for adding e-signatures to mobile apps, websites and platforms, with an OEM and embedded partner route for software companies that resell signing.
airSlate SignNow API
An embeddable API for signing, sending and editing documents, shipped with branding controls, webhooks, an SDK and a ready-made Postman collection for your first calls.
BoldSign API
A developer-focused signing API built around templates and one-call sending, handy when your app fires off the same agreement over and over.
Documenso
Bills itself as the open source Docusign alternative: run it on your own servers, or build on top of its developer tools.
DocuSeal
Open-source document signing with its own API, embedded signing and an on-premises install, aimed at teams wiring signatures into automations.
Docusign eSignature API
The big agreement platform's REST and SOAP signing APIs, sitting beside separate Click, Rooms, Notary and Web Forms APIs if signing grows into more.
Dropbox Sign API
The signing API behind Dropbox Sign, still documented on its old HelloSign domain, with custom branding, a test demo and published rate limits.
PandaDoc API
A document API first: build from templates, send, collect signatures and track status, with webhooks and a sandbox for trying calls safely.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
SignWell API
A signing API that ships a CLI and an MCP server, so requests can go out from a terminal or straight from an AI chat.
Zoho Sign API
Zoho's digital signature API for sending, signing and managing paperwork from inside your own application, an easy fit if your business already runs on Zoho.
Hosting it yourself: what you take on
Self-hosting looks like the cheap, private option, and on licence fees it often is: at least one open-source edition on this page is listed by its maker as free to deploy. What you're really doing is swapping a vendor's bill for your own team's hours. Installs, upgrades, security patches, backups, keeping the audit trail intact, and someone on call when a signing link breaks on the last day of the month. If you have that team, a self-run open-source signer gives you control no hosted API can. If you don't, a hosted API will cost you less once you count those hours.
There's a middle path. Some open-source signers also sell a hosted cloud version alongside the self-run one, so you can start hosted and move in-house later. Before you do, ask how templates, signed files and audit records move between the two.
What the bill is made of
Across the pricing pages I checked in November 2026, the range runs from free (a self-hosted open source install, where you pay for servers and staff instead) through to monthly plans in the tens of dollars to start. The top end isn't published in a way I could pin down, so treat anything beyond the starter plans as a quote you negotiate on volume. Usage-priced APIs charge well under a dollar for each completed document or envelope on top. Some APIs bill per envelope with a monthly minimum, some per completed document, and some bundle API access into a per-sender subscription. Prices change, so read the vendor's page on the day you buy.
Three numbers decide where you land: documents sent each month, how many senders and templates you need, and which extras you want, such as your own branding, SMS delivery or identity checks on signers. Work those out first, then ask each vendor what happens if your volume doubles. The jump between tiers is where budgets get caught out.
An hour with two sandboxes
Take a real document. A two-page order form works well: the customer's name, company and order total filled in from your own data, plus two signers, the customer and someone on your side who countersigns. Open test accounts with two APIs of the same shape. In each, create the document, send it, sign the first copy on your phone and the second on a laptop, and log every webhook your app receives. Then download the signed PDF and the audit record and store both where your app keeps files today.
Score each API on four things: minutes from API key to first fully signed document; whether the phone signing screen worked without pinching and zooming; whether the webhooks told you who signed and when without a second call; and how clear the error was when you deliberately sent a broken field. Weight the last one most. Your developers will read far more error messages than feature pages.
While you're in there, watch for the traps that send teams back to the start. Polling for status instead of listening for webhooks works fine in testing and hits rate limits at volume; Dropbox Sign publishes its limits, so find the same page for your pick before launch. Keeping the signed PDF and binning the audit record leaves you with nothing to show if a signature is disputed. Testing on a desktop only misses how most people sign, from an email on their phone. And an unfamiliar sender name on the signing request is the quickest way to get a contract left unopened, so check what yours will say.
Two names to double-check before you build
Yousign's site now says 'Yousign becomes Youtrust', so a well-known European eSignature API is mid-rebrand, and I've left it off rather than list it under a name that may not last. Dropbox Sign is the gentler case: its developer docs still sit on the HelloSign address it grew up on. Either way, check the company name on the contract, the SDK package names, the domain your webhooks come from and where the docs will live in a year. A rename can bring new endpoints, new credentials or a migration nobody planned for.
Where I'd start
Signing is a feature inside your SaaS and should feel native? Take two from the embedded group and run the hour-long test this week. Customers already live in a big agreement platform? Go with a wider suite and don't fight it. Documents start life as data? A documents-first API saves you a whole build. Data residency is non-negotiable and you have people to run servers? One of the open source pair. And if your team already does half its work through an AI assistant, keep the CLI and MCP route in view, even if it isn't your main pick yet.
If the documents your users sign start life as contracts you draft yourself, my list of AI contract generators covers the step before the signature.
Do you make eSignature APIs or document signing tools for developers? Tool makers can ask to be considered for a featured place on this list.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
