Put signing inside your own product.

Is the eSignSimple API live?

Your own software can now create documents, send them for signature, track their status and download signed copies without anyone logging into a dashboard. The REST API lives at https://esignsimple.com/api/v1, and the full reference with request and response examples is on our developers page.

Signers reached through the API get exactly the same account-free signing experience and the same evidence as documents sent from the dashboard: an audit trail, a certificate of completion and a SHA-256 hash that anyone can check on our public verify page.

How does the API work?

Create a document with POST /documents. You send a multipart request with the PDF and a JSON part listing signers and fields, where field positions are given as fractions of the page, so you do not need to care about PDF points or page sizes. The document is sent immediately, or kept as a draft if you pass send:false.

Already have a template in the dashboard? POST /templates/{id}/send fills in the signers and sends it. GET /documents lists your documents with a status filter and cursor pagination via before. GET /documents/{id} returns the status, the signers and the full audit trail, and GET /documents/{id}/download returns the signed PDF once the document is completed, or the original with ?file=original.

You can also void a document in progress with POST /documents/{id}/void, delete one with DELETE /documents/{id}, and check your plan and current usage with GET /me.

How do authentication and API keys work?

Every request uses a Bearer API key. You create and revoke keys in Settings → Developers. A key is shown once when you create it and we store only a hash, so copy it into your secret manager straight away. If a key leaks, revoke it and create a new one; nothing else has to change.

The same API also accepts Firebase ID tokens, which is what our upcoming mobile app will use. That is a deliberate choice: we build our own apps on the same public API you use, so it gets exercised every day.

Which webhooks can you receive?

Instead of polling, register one HTTPS endpoint for your account and we will notify it when something happens. Events are document.completed, document.declined, document.voided and signer.signed.

Each delivery is signed with HMAC-SHA256 and the signature is sent in the esign-signature header, so you can confirm the request really came from us before acting on it. If your endpoint fails, we retry once. Our advice: treat webhooks as a trigger and call GET /documents/{id} for the authoritative state.

What do people build with the API?

A CRM or quoting tool that sends a contract the moment a deal is marked as won. An HR system that sends an onboarding pack from a template when a hire is confirmed. A property tool that sends a lease and files the signed PDF against the unit when document.completed arrives. An internal script that stops someone copying rows from a spreadsheet into contracts by hand.

If you send a handful of documents a week, you probably do not need the API at all. Templates, bulk send and web forms in the dashboard will cover you with far less effort.

How is the API priced?

There is no separate API price list. The REST API and webhooks are included in Silver ($9.99 a month) and Gold, both with unlimited documents (see pricing). Documents created through the API count exactly like documents sent from the dashboard.

Large providers such as DocuSign, Dropbox Sign and Adobe usually price their APIs separately from user plans, often based on annual envelope volumes, and entry API plans can cost significantly more than their standard subscriptions. Check their websites for current pricing.

What is not included yet?

We are honest about the gaps. There is no embedded signing iframe yet, so signers still sign through the link we email them. There are no official SDKs; the API is plain HTTP and JSON, so any language with an HTTP client works. There is no separate sandbox environment, so test on your own account with drafts and your own email addresses. All of these are on our roadmap.

Why did we start with a small API?

We deliberately started narrow. A small API that does the common workflow well, with predictable limits and no sales call, is more useful than a huge surface that takes weeks to integrate. If something you need is missing, tell us what you are building; real integrations decide what we add next.

What does a minimal API integration look like?

Most integrations need three calls and one webhook. First, POST /documents as multipart/form-data with two parts: file (the PDF, or a .doc, .docx, .odt or .rtf file that we convert to PDF, up to 25 MB) and data, a JSON string with a title, a signers array of names and emails, and a fields array. Each field names the signer by their index in the signers array, a kind, a page number and x, y, w and h as fractions of the page measured from the top-left corner. So a signature box in the lower right of page 2 might be page 2, x 0.55, y 0.8, w 0.35, h 0.06.

Field kinds are signature, initials, date, name, email, text, company, title, number, checkbox, dropdown and radio; dropdown and radio take a list of 2 to 20 options. Set sequential to true if signers must sign in the order of the array. The response is the document with an id, a status of sent (or draft if you passed send false) and each signer's status.

Second, wait for document.completed on your webhook, or poll GET /documents/{id}. Third, GET /documents/{id}/download to fetch the signed PDF and store it next to your own record. That is the whole loop: create, wait, download.

Which errors will you see, and how do you fix them?

Every error is JSON with an error object holding a code and a human-readable message, so log both. 401 unauthorized means the Authorization header is missing or the key is not valid. Keys are tied to a Silver or Gold plan, so a key also stops working if the account moves to a lower plan. 400 invalid_request covers malformed input: data that is not valid JSON, a missing file, or a field that refers to a signer index that does not exist. The message tells you which.

413 too_large means the file is over 25 MB; compress scanned PDFs or split long appendices. 422 conversion_failed means we could not convert a Word or other non-PDF file; exporting it to PDF yourself and sending that usually solves it. 404 not_found means the document or template id does not exist or belongs to another account. 409 not_completed comes from the download endpoint when you ask for the signed PDF of a document that is still out for signature; ask for ?file=original instead, or wait for completion.

If a document cannot be deleted, it is probably still out for signature. Void it with POST /documents/{id}/void first, then DELETE it. Deleting is permanent, so in most integrations voiding is the right action and deletion is only for drafts and test data.

How do you verify a webhook and handle failures?

Every delivery is a POST with a JSON body containing an event id, a type, a created_at timestamp and a data object. For document.completed, data includes the document id, the title, the completion time and the SHA-256 fingerprint of the final PDF. The esign-signature header carries a hex-encoded HMAC-SHA256 of the raw request body, computed with the secret you received when you registered the endpoint.

To verify, compute the HMAC over the exact bytes you received, before any JSON parsing or re-serialising, and compare it with the header using a constant-time comparison. Reject anything that does not match. Return a 2xx status quickly and do the slow work, such as downloading the PDF, in the background. We wait up to 10 seconds and retry a failed delivery once after about 5 seconds; after that we stop.

Because there is only one retry, do not let webhooks be your only source of truth. A nightly job that lists documents with status=completed and checks which ones your system has not stored yet catches anything missed during downtime. Store the event id, too: if you ever receive the same event twice, you can ignore the duplicate.

How do you test an integration without a sandbox?

Create drafts with send set to false while you work on field positions. A draft is not sent to anyone and does not count towards a plan's document total, and you can open it in the dashboard to see where your fractions placed each field. Delete test drafts when you are done. When the layout is right, send real documents to signer addresses you control, such as your own inbox with plus-addressing if your mail provider supports it.

Use the list endpoint's status filter and pagination to check your sync code: limit takes 1 to 100 (default 20), and when has_more is true, pass next_before as the before parameter for the next page. If you want to see how the evidence looks before you wire anything up, complete one test document and check its fingerprint on our verify page.

Which API endpoints exist today?