How to build a legally binding e-signature API

A signature API is legally binding in the United States when it proves four things: the signer intended to sign, consented to do business electronically, could be tied to the signature, and the record of what they signed was kept intact. The code that renders a "Sign" button is the easy part. The evidence your API produces is what matters in a dispute.

This guide walks through the legal baseline (ESIGN and UETA), the flow your API should follow, the records it must preserve, how to protect them, and how to test and maintain the system. It is written for developers, CTOs and general counsel who need to ship signing inside a product.

TL;DR

• Federal law says a signature cannot be denied effect solely because it is electronic. A typed name or a click can qualify if you can attribute it to the signer.
• Build the flow around consent, identity, intent and a clear Sign action, then bind the signature to a hash of the exact document.
• Keep an audit trail with timestamps and signer data, and make it exportable independent of any vendor.
• Some documents, such as wills and UCC Article 2 records, are outside the general rule and need paper or special procedures.
• You can build this yourself or embed an API that already does it. Either way, test the evidence, not just the endpoints.

What makes an electronic signature legally binding in the US

Two laws set the baseline. The federal ESIGN Act of 2000 provides that a signature, contract or record in interstate or foreign commerce may not be denied legal effect or enforceability solely because it is in electronic form. The Uniform Electronic Transactions Act (UETA) does the same at the state level. According to the American Bar Association, UETA has been adopted by 47 states with rules substantially similar to ESIGN.

Neither law demands a particular technology. There is no required certificate, no mandatory cryptographic scheme, and no rule that a signature must look handwritten. The same ABA piece notes that a typed name can be binding if it is attributable to the signer and the parties agreed to transact electronically.

That shifts the engineering question. You are not asking "is this signature technically valid?" You are asking "could we prove, two years from now, who signed what, when, and that they meant to?"

The elements your API has to prove

1. Intent to sign. The signer took a deliberate action, such as clicking a clearly labeled button after seeing the document.
2. Consent to transact electronically. Both parties agreed to use electronic records and signatures.
3. Attribution. The signature is linked to a specific person through your identification process.
4. Association with the record. The signature is tied to the exact document version that was signed.
5. Retention. The record can be stored and accurately reproduced later.

Every design decision below serves one of these five.

Consumer consent: when it gets stricter

Business-to-business signing is relatively light on formalities. Consumer transactions are not. When a law requires information to be provided to a consumer in writing, the business must obtain the consumer's affirmative electronic consent and show the consumer can access the information in the form used, as described in the FTC's report to Congress on ESIGN. Section 101(c)(1)(C)(ii) requires that consent be obtained in a way that reasonably demonstrates the consumer can access the electronic form.

In practice, if your product signs agreements with consumers, your API should:

• Show a plain-language electronic disclosure before the document.
• Require an affirmative action, not a pre-checked box.
• Test access in a way that matches the format you will deliver, for example by asking the signer to open a PDF or enter a code shown inside one.
• Store the disclosure version and the consent event alongside the signature.

If you only sign B2B contracts such as MSAs, SOWs, NDAs and order forms, you still want a clear agreement to sign electronically. It costs one line in the flow and removes an easy objection.

The signing flow, step by step

A practitioner checklist from McLaw describes the sequence: disclose electronic signing, obtain consent, issue unique signer credentials, present the document before a clear Sign action, and capture the document hash. Here is how that maps to an API design.

1. Create the envelope and define the signers

Your backend creates a signing request containing the document, the signer's name and email, and the fields to complete. Treat the document as immutable from this point. If anyone edits it, create a new version and a new request.

2. Issue a unique, single-purpose signer link

Each signer gets their own credential: a long, random, expiring token bound to one envelope and one recipient. Never reuse links across signers. Never put the token somewhere it can leak, such as a URL logged by third-party analytics without protection.

3. Identify the signer proportionally

Email-based access is enough for many commercial agreements. Higher-value or higher-risk deals justify more: a one-time passcode by SMS, a second factor, or a knowledge check. The law does not prescribe the level. Match it to what you would need to defend if the signer later said "that wasn't me."

4. Present the document before the Sign action

The signer must be able to see the full document, ideally forced to scroll or at least given full access, before the signing control becomes active. Label the control honestly. "Sign and agree" is clearer than a generic "Submit."

5. Capture the signature and bind it to a hash

When the signer acts, compute a cryptographic hash (SHA-256 is the common choice) of the exact document bytes they saw, and store it with the signature event. If the document is later altered, the hash will not match. This is what turns a picture of a signature into evidence tied to a specific version.

6. Seal and deliver

After all parties sign, produce the final PDF with a completion certificate, send copies to every party, and make them retrievable by authenticated request.

What the audit trail must contain

The audit trail is your proof. The McLaw checklist says a valid process should document the signer's identity and intent, typically capturing timestamps, IP addresses and device fingerprints in a completion certificate or audit trail. Log at minimum:

Two principles matter more than the exact fields.

Retention and reproducibility. The FTC has said in an advisory opinion on electronic authorization that a consumer's authorization must be retainable and accurately reproducible for later reference. Design your storage so you can regenerate the signed document and its certificate years later.

Independence from the vendor. The same checklist treats it as best practice to export and keep the audit trail, completion certificate and the version of the document as the signer saw it, independent of the e-signing vendor's platform. If you use a third-party API, pull these records into your own storage on completion through a webhook.

Protecting signing events from tampering and fraud

A legally defensible record is also a secure one. These are the controls we would expect in any signing API.

• Encrypt in transit and at rest. Serve every endpoint over TLS. The OWASP REST Security Cheat Sheet is a good checklist for API keys, rate limiting (return 429 when limits are exceeded) and input handling.
• Authorize every object. A signer token should open one envelope only. Check ownership on each request, not just at login. Broken object-level authorization is the first item on the OWASP API Security Top 10.
• Make the record append-only. Audit events should be written once and never updated. If you need a correction, add a new event.
• Sign your webhooks. Verify an HMAC signature on every callback so that nobody can fake a "completed" event to your system.
• Seal the final PDF. Apply a cryptographic seal so any later change is detectable by standard PDF readers.
• Expire and revoke. Signer links should time out, and senders should be able to void an envelope before completion.
• Rate-limit and monitor. Repeated failed passcode attempts or token guessing should trigger lockouts and alerts.

None of this is exotic. The failure mode is usually a missing check on one endpoint, which is why testing matters.

Documents that need paper or special handling

E-signatures are not universal. The ABA notes that documents outside ESIGN and UETA typically include those governed by Article 2 of the Uniform Commercial Code, plus wills, codicils, testamentary trusts, powers of attorney and certain divorce decrees or court orders. Some family-law documents may also be ineligible.

If your platform serves a vertical such as real estate, lending or healthcare, build a document-type allowlist. Flag any type that may need wet ink, notarization or a state-specific procedure, and have counsel review that list. Do not let a user send a will through a general contract flow and assume it works.

Common commercial agreements are the sweet spot: NDAs, MSAs, DPAs, SOWs, LOIs, order forms and pilot agreements. Even a sales quote can be signed electronically, and a guide to e-signing a sales quote shows how that plays out in a quoting workflow.

Signature or clickwrap?

Not every acceptance needs a signature flow. For a terms update sent to a very large user base, a clickwrap acceptance with logged consent can be the better tool. We cover that tradeoff in our post on clickwrap versus e-signature. Use full signing when the agreement is negotiated, high value, or needs a named counterparty on a completion certificate.

Testing, deploying and maintaining the API

A signing API fails quietly. A missing log line looks fine until a dispute. Treat evidence as a feature with its own tests.

Before launch

1. Run an end-to-end evidence test. Sign a document in a staging environment, then reconstruct from storage alone who signed, when, from where and which version.
2. Tamper test. Alter one byte of the signed PDF and confirm your verification fails.
3. Authorization test. Try one signer's token against another envelope. It must be refused.
4. Webhook test. Replay old callbacks and send forged ones. Your handler must reject both.
5. Accessibility and device test. Complete signing on mobile and with a screen reader. Consent that a signer cannot operate is weak consent.
6. Legal review. Have counsel approve the disclosure text, the document-type allowlist and the certificate wording.

After launch

• Rotate API keys and signing secrets on a schedule.
• Monitor failed verifications, expired links and webhook errors.
• Keep disclosure versions and templates under version control, and record which version each signer saw.
• Back up audit data and test restores.
• Re-check your document-type rules when state law or your customer mix changes.

Language-specific walkthroughs help with the implementation details. We have written them for Node.js, Python, Java and .NET.

Build or embed?

Building gives you full control, and it also gives you the whole evidence burden: hashing, sealing, certificates, retention, key management and ongoing legal review. Embedding an existing API moves much of that to a vendor, while you keep ownership of the user experience and your own copy of the records.

A reasonable rule: build only if signing is your core product. If it supports a different product, embed. Our developer guide to implementing e-signing and our overview of how an e-signature API collects binding signatures cover the architecture in more depth.

Our perspective: evidence first, interface second

We build contract workflow software, so we see where signing sits in a deal. A signature is the last step in a chain: drafting, review, negotiation, redlining and then signing. Disputes rarely start at the signature. They start when nobody can show which version was agreed.

That is why we treat the audit trail as the product, not an add-on. When drafting, redlines and signing live in one workflow, the history of changes and the signature record come from the same system. There is no export from one app and import into another where context gets lost.

For teams embedding signing, our advice is simple. Decide what evidence you want to be able to produce, write it down, and then check that your API produces it automatically on every envelope. Legal and engineering should agree on that list before the first customer signs.

— Alex

Embed signing with Formable

If signing is a feature of your product rather than the product itself, our embedded e-signing API lets your app collect signatures with audit trails, and our redlining API adds tracked changes for negotiated agreements. For developers there is a Growth plan at $29.99 per month on the API pricing page, and a Developer plan listed there too. You can read how we handle security and legally binding e-signatures before you decide. For teams who just want to send documents for signature, Formable E-Signing works without any code.

FAQ

Does a typed signature legally bind?

It can. Under ESIGN, a signature cannot be denied effect only because it is electronic, and the ABA notes a typed name can be binding if it is attributable to the signer and the parties agreed to transact electronically. Your API's job is to capture the evidence of that attribution and agreement.

Do I need a digital certificate to create a legally binding signature?

Not under the federal framework described above, which does not mandate a specific technology. A certificate-based digital signature can strengthen tamper evidence and identity, but a well-documented process with consent, intent and an audit trail is what the law looks at. Some regulated industries or foreign jurisdictions may require more, so ask counsel.

How do I make a signing API secure?

Use TLS everywhere, authorize every object request, sign webhooks, keep audit logs append-only and seal completed PDFs. Follow the OWASP guidance linked above for API keys, rate limiting and the most common API vulnerabilities. Then test for tampering and token misuse before launch.

Which documents cannot be signed electronically?

Wills, codicils, testamentary trusts, powers of attorney, some family-law documents and records governed by UCC Article 2 may fall outside the general rule. Rules vary by state and document type. Check with a licensed attorney in the relevant state before putting these through an e-signature flow.

Sources

• 15 U.S.C. § 7001: General rule of validity
• Electronic Signatures and Legal Opinions, American Bar Association
• FTC report to Congress on the ESIGN consumer consent provision
• FTC advisory opinion to Zalenski
• Electronic Signature Implementation Checklist, McLaw
• REST Security Cheat Sheet, OWASP
• OWASP API Security Top 10 (2023) explained