What is an eSignature API?

An eSignature API lets your software send documents for electronic signature without anyone opening the provider's website: you upload a PDF or use a template, name the signers, place the signature and form fields, and send. The provider emails the signers, records the audit trail, and notifies your application through webhooks when the document is viewed, signed or declined.

How do I choose an eSignature API?

Compare pricing per document against flat plans at your real volume, embedded signing if signers stay inside your app, templates and text tags for placing fields, webhook verification, a test mode, where the data is stored, and the audit trail you get with each signed document. Most providers cover the basics; the differences are in pricing and in how well their webhooks behave.

Are electronic signatures legally binding?

In the United States, electronic signatures are recognized under the federal ESIGN Act and the state-level UETA, and in the European Union under the eIDAS regulation, with some document types excluded. Check with a lawyer for your documents and jurisdictions; the provider's audit trail is the evidence you will rely on.

How do eSignature webhooks work?

The provider calls a URL you register each time something happens to a document: sent, viewed, signed, completed, declined. Your application should verify that each call really comes from the provider, using the signature or hash the provider attaches, and should treat the call as a hint to fetch the document's current state rather than as the only record.

How much does an eSignature API integration cost?

The provider charges per document or per plan. The integration is the larger cost: at Reflekt Lab a first integration flow in production costs $5,000 to $18,000, then from about $470 a month for maintenance.

eSignature API Integration: What to Build Around the API

A signed document resting on a relay box connected to a cloud on one side and two applications on the other, with a seal on the outgoing line

An eSignature API lets your software send documents for signature and learn when they are signed, without anyone opening the provider's website. You upload a PDF or use a template, name the signers, place the fields and send; the provider handles the emails and the audit trail, and calls your application back through webhooks as the document moves. Choosing the API is the easy part, since most cover the basics. The work is around it: verifying the provider's webhooks, getting each event to the right application even when it is briefly down, keeping the signed PDF, and keeping sensitive answers out of your logs. Below: how to choose, and what we built around our provider in production.

What an eSignature API does

Every serious provider covers the same core:

Create a document from a PDF or a template, with one or more signers and a signing order.
Place fields: signatures, initials, dates, text, checkboxes. By coordinates, or with text tags written in the document itself, which the provider turns into fields.
Send it, by email or as an embedded signing page inside your application.
Report progress through webhooks: sent, viewed, signed, completed, declined.
Return the signed PDF and an audit trail of who signed what, when, and from where.

In the United States, electronic signatures are recognized under the federal ESIGN Act and state laws based on UETA; in the European Union, under eIDAS. Some document types are excluded, so check yours with a lawyer.

How to choose one

Instead of ranking vendors, compare them on what will actually differ for you:

Price at your real volume. Per-document pricing is cheap at 20 a month and expensive at 2,000; flat plans are the reverse.
Embedded or email signing. If signers stay inside your app, check how embedded signing looks and what it costs.
Text tags and templates. Tags in the document are far easier to maintain than coordinates.
Webhooks you can verify. Every call should carry a signature or hash you can check.
A test mode that sends nothing legally binding.
Where documents are stored, and for how long.

We use SignWell. The rest of this post applies to any provider.

What we built around it

Our CRM sends deal contracts and partner agreements for signature, and other applications were going to need the same. Rather than wiring the provider into each one, we put a small service in front of it, in production since December 2025. Every application talks to that service; only the service talks to the provider.

One key, one place

The provider's API key lives in one service. An application asks it to create a document and registers the callback URL where it wants to hear about that document. Callback registrations expire after 30 days by default.

Verify every webhook, exactly as sent

SignWell signs each webhook with a hash: an HMAC-SHA256, keyed with your webhook ID, of the event type and the event time joined by @. Our service recomputes it and rejects anything that doesn't match.

The trap: use the event time exactly as the provider sent it. Parse it into a date and print it back, and the formatting changes, the hash no longer matches, and every genuine webhook is rejected. Keep the literal string.

Forward with retries, and only retry what can succeed

When a verified event arrives, the service forwards it to the callback URL registered for that document:

Retries with backoff: after 1, 2 and 4 seconds, so a deploy or a short outage at the receiving application doesn't lose the event.
No retries for permanent failures: a malformed or forbidden callback URL fails once and is reported.
Signed forwards. Each forwarded event carries a signature header (RSA-PSS or ECDSA, over SHA-256), so the receiving application can check that it came from our service and wasn't altered.

Don't let a callback URL become an attack

A service that calls URLs given to it is an open door if you are careless:

Private and internal addresses are refused. The check happens when the connection is made, after DNS resolution, so a hostname can't be pointed at an internal address after it was validated.
The service refuses to call itself. We learned this one the hard way: a callback URL pointing back at the service re-entered its own webhook endpoint, and the event never stopped bouncing. Now it is rejected, and a missing configuration for the check is reported at startup.

Keep the signed PDF and the answers, carefully

When a document completes, the receiving application downloads the signed PDF and the answers signers typed into the fields. In our CRM:

Sensitive answers are sealed. A field such as a bank account number is encrypted before it is stored; if no encryption key is configured, it is not stored at all, since the signed PDF still carries it.
The audit log is redacted. Every webhook is logged for traceability, with sensitive values replaced. Logs count answers and name fields, never print values.
Failures there never undo a signature. The signature already happened at the provider; if storing the PDF or the answers fails, it is logged, never reported as a failed signature.

What it costs

The provider charges per document or per plan. The integration is the bigger cost, and it is mostly the work described above. Our published prices: a first integration flow in production costs $5,000 to $18,000, then from about $470 a month for maintenance. More on API integration services.

Questions to ask before you integrate

How many applications need signatures? More than one is a reason for a service in front of the provider.
How do you verify the provider's webhooks?
What happens if your application is down when the "signed" event arrives?
Where does the signed PDF end up, and who can open it?
Which fields are sensitive, and do they reach any log?