Electronic Signature API: Status and Early Access

An electronic signature API is a programmatic interface that lets your own software send documents for signature and receive the signed result, without anyone using a dashboard. Instead of a person uploading a file, placing fields, and clicking send, your application makes an HTTP call that does all of it, then listens for a webhook callback to know when the document has been signed.

The practical difference is control and scale. A signing dashboard is for a human sending a handful of documents. An API is for a system that needs to send signing requests as part of a product feature or an automated process, whether that is one a day or thousands a month. Most established e-signature vendors expose this as a REST API with JSON payloads plus webhooks, usually gated behind a developer or enterprise tier and often metered per envelope.

You need an API when signing is embedded in software or a repeatable workflow. Common triggers: you are building a SaaS product and want customers to sign agreements inside your app, you send the same contract or onboarding packet at high volume, you want a CRM or internal tool to fire off an agreement automatically when a deal moves stage, or you need signed files to land in your own database without anyone touching them. If that is you, and you need it now, you should be evaluating vendors that already ship a live API. We are not going to pretend we are one of them.

You do not need an API when a person is comfortable sending documents by hand from a dashboard. If your team sends a few contracts a week and a human is already in the loop, a normal send-for-signature workflow is simpler and cheaper, and you can skip the integration entirely. Many businesses that think they need an API are well served by the standard electronic signature software and never write a line of code. That workflow is live in SignSend today, and it is free to try.

Everything in this section describes an interface we intend to ship. None of it exists yet, none of these endpoints will answer if you call them, and the shape may change before release. We are publishing it so you can judge whether the eventual API would fit your stack, and so you can tell us if it would not.

• Planned: create a signing request. A single authenticated POST that will take the PDF, the list of signers, and the field positions, and will return an identifier plus a signing link per signer.
• Planned: fetch document status. A GET that will return each signer's state (sent, viewed, signed) so an integration can poll if it prefers not to use callbacks.
• Planned: download the signed file and audit trail. Endpoints that will return the completed PDF and the structured audit record, including timestamps, IP addresses, and the SHA-256 hashes SignSend already stores today.
• Planned: webhooks. Registering an endpoint that receives an event when a document is viewed, signed, or completed, so your application can advance a workflow without polling.
• Planned: API keys. Per-account keys you can issue and revoke, so an integration is not tied to a user session.

To be completely clear about status: the application currently exposes no public REST endpoints at all. There is no sandbox, no beta key, and no documentation to hand out yet, because there is nothing behind it. When there is, everyone on the early access list hears first.

If your volume is low enough that a person can stay in the loop, the live product may already be enough. Today, from the dashboard, you can upload a PDF up to 20MB, add signers by name and email, and place the signature field on the page. Each signer is emailed a unique, expiring link and signs in the browser, drawing a signature or typing their name, with no account to create and no seat to pay for. The signature is stamped into the PDF, the signed copy is emailed back to everyone, and it stays downloadable from your dashboard.

Every document also carries an append-only audit trail recording uploaded, sent, viewed, signed, and completed events with actor, IP address, user agent, and timestamp, plus a SHA-256 hash of both the source and the signed file. Signatures collected this way are valid under the federal ESIGN Act and state UETA laws. The free plan covers 3 documents a month with up to 2 signers, which is enough to test the whole flow end to end before you commit to anything. Technical teams sizing this up can also read the electronic signature for IT and software companies page.

Only the free plan is available to buy today: $0, 3 documents a month, up to 2 signers, no credit card. Paid Pro and Business tiers are announced at $12 and $29 a month but are marked coming soon on the pricing page and cannot be purchased yet. We have not decided which tier the API will land on or what it will cost, so we are not quoting a price for it here.

Early access is a mailing list, nothing more. Email [email protected] with a line about what you would build and we will add you. There is no form, no signup, no charge, and no obligation. If your use case would not be served by what is planned above, tell us that too, it is more useful than a waitlist entry. For a broader look at how flat-rate signing tools compare, see the best e-signature software for small business roundup.