Electronic signature API: a developer's guide
An electronic signature API lets your application send documents for signature programmatically, instead of a person manually uploading a file through a web dashboard every time. In practice, that usually breaks down into four steps: authenticate your requests with an API key, upload the document, create a signature request with the signers and fields you need, and then track or react to its progress. This guide walks through each step at a conceptual level before the following articles in this series get into specific languages and edge cases.
Why a REST API instead of a dashboard
A dashboard works fine when a person is sending one document at a time. It stops working once sending a document is something your own application needs to do automatically — a contract generated after a sales call, an onboarding packet triggered when someone signs up, a vendor agreement created from data already sitting in your database. A REST API lets that process happen without a human opening a browser tab, which is the entire point of integrating one into your own product or internal tooling.
The basic building blocks
- Authentication: every request identifies which developer account it belongs to, typically through an API key sent in a header. See API keys and authentication for e-signature APIs for exactly how that works.
- Document upload: the file you want signed, usually sent as the raw content (often base64-encoded) along with its filename and MIME type.
- Signature request creation: this is where you specify who needs to sign, in what order if it matters, and which fields (signature, initials, date, text) go where on the document.
- Status and completion: a way to check whether the request is still pending or complete, either by polling an endpoint or by reacting to a webhook when something happens. See E-signature webhooks explained for the webhook side of this.
A typical request flow
- Upload the PDF you want signed, and get back a document identifier.
- Create a signature request referencing that document, with a list of signers (email, and optionally a name) and the fields each of them needs to complete.
- Each signer receives a secure, individually addressed signing link by email — the same kind of link a person would get if you'd sent the document manually through the dashboard.
- As signers complete their part, you can check progress by querying the request's status, or by listening for a webhook event when a signer finishes or the whole request completes.
- Once everyone's done, download the final signed document and its completion certificate for your own records.
Where fields come into this
Positioning fields through the API means specifying, for each field, which page it belongs to, its coordinates on that page, its type (signature, initials, date, text, and so on), and which signer it's assigned to. This is the same positioning concept used in the dashboard's visual editor, just expressed as structured data instead of dragging a box on a page. See Placing signature fields in PDFs via API for the specifics of how that's structured.
Authentication in brief
Esignapi's API uses a header-based API key rather than OAuth or session cookies — you generate a key from your account settings and send it with every request. Keys are tied to your developer account and, depending on how your account is set up, to a specific workspace within it. The full breakdown, including the exact key format, is in API keys and authentication for e-signature APIs.
Synchronous calls vs webhooks
Creating a signature request is a synchronous API call — you get an immediate response confirming the request was created. What happens after that (a signer opening the link, completing fields, finishing the document) happens asynchronously, often over hours or days, which is why polling an endpoint repeatedly isn't the most efficient way to track progress. A webhook, where Esignapi sends your application an HTTP notification when a signer completes a document or when the whole request finishes, is generally the more practical approach for anything beyond occasional manual checks.
What you need before you write any code
- An account with API access on your plan — API access is available starting on the Pro plan, not on the Free or Starter tiers.
- An API key generated from your account settings.
- A PDF to test with, and at least one email address you control to act as a test signer.
Where this fits for different kinds of integrations
A one-off internal tool — say, a script your HR team runs to send onboarding paperwork — can get away with a fairly simple, linear integration: upload, create, wait, download. A customer-facing SaaS product that needs e-signature baked into its own workflow usually needs more: webhook handling for real-time status, error handling for failed uploads or expired links, and a plan for what happens if a signer never completes their part. See Adding e-signatures to a SaaS product for that fuller picture.
Build vs. integrating an existing API
Before integrating any third-party e-signature API, it's worth being clear on why you're not building this yourself — legally valid electronic signatures need to meet real requirements around identification, consent, and record integrity, and reproducing that correctly (plus maintaining it as laws and expectations evolve) is a meaningfully different project than most product roadmaps have room for. See Build vs buy: should you build your own e-signature? for a fuller comparison.
A note on terminology before you dig into the specifics
Across this and the other articles in this series, a few terms come up repeatedly worth clarifying upfront: a "signature request" is the overall record covering one document and its full set of signers; a "signer" is an individual person assigned to complete some subset of fields on that request; and a "field" is a single positioned element — a signature, initials, a date, a line of text — that a specific signer needs to complete. Keeping these three distinct matters once you start reading request and response payloads, since a request can have many signers, and each signer can have many fields, all nested within the same overall request structure.
How this series is organized
The rest of this series goes deeper on each piece introduced here: authentication and key management, webhook events and their real limitations, field positioning in detail, language-specific code examples, error handling and the realistic limits of duplicate protection, rate limiting, testing without a dedicated sandbox, embedding request management in your own product, and the broader build-vs-buy decision behind using an API at all. Read them in whichever order matches what you're actually building next — there's no strict prerequisite order beyond understanding the basic request flow covered here first.
A realistic first integration milestone
Rather than aiming to build a complete, production-ready integration on the first attempt, a reasonable first milestone is simply: upload one real PDF, create a signature request with yourself as the only signer, and successfully receive and complete that signing link. Getting that single round trip working end to end confirms your authentication, your request formatting, and your basic understanding of the flow are all correct — and gives you a working foundation to build the rest of the integration (multiple signers, fields, webhooks, error handling) on top of incrementally.
Start building
Esignapi's API documentation covers the exact endpoints, request and response formats, and authentication details referenced throughout this guide, with working code examples in multiple languages.
Frequently asked questions
Do I need a paid plan to use the API?
Yes — API access is included starting on the Pro plan. The Free and Starter tiers are designed around the dashboard-based sending flow rather than programmatic access.
Can I test the API before committing to building a full integration?
You can create a real signature request using your own email address as the test signer, which lets you see the full flow — upload, creation, signing link, completion — without needing a dedicated sandbox environment. See Testing e-signature integrations safely for more on this approach.
Does the API support multiple signers with a signing order?
Yes, the same signing-order functionality available in the dashboard — parallel or sequential signing — is available when creating a signature request through the API.
The final signed document is a PDF with every signature embedded, available for download once the request is complete, along with a separate completion certificate summarizing the signing record.
Is there a difference in legal validity between a document sent through the API versus the dashboard?
No — both paths go through the same underlying signing process (identification, intent, record integrity), so the legal validity of the resulting signature doesn't depend on which interface was used to create the request.