SignSealer API documentation

Signatures, and the evidence behind them. One API for waivers, rental agreements, NDAs and contracts.

What makes an electronic signature enforceable under ESIGN and UETA is evidence of five things. Cryptography is how that evidence is kept tamper-evident, and SignSealer uses it throughout; it is the record it protects that a court reads.

Intent — the signer meant this act to be their signature.
Consent — they agreed to do business electronically, before signing.
Association — the signature is attached to this record and no other.
Attribution — it can be shown to be them.
Retention — the record can be accurately reproduced later.

Courts have thrown signatures out for missing the fourth. So SignSealer records each of the five as its own event, hashes the exact text into every one, chains the trail so nothing can be edited afterwards, and seals the finished document so that a single changed byte shows, with the time of sealing fixed by an independent RFC 3161 timestamp authority.

What that means in practice

Consent is recorded as its own event, before the signature is accepted — not alongside it, because a system that records both in the same instant cannot show that consent came first.
The rendered text is stored on the document and hashed into every event. A document edited after signing no longer matches, and we say so.
A published template cannot be edited. Revising it makes a new version, because editing one changes what people signed last week.
The trail is append-only. A record that can be edited is a record of what somebody was willing to leave behind.

Where to start

How-to videosShort films of each part of SignSealer, from the first day to the API, each with its guide. QuickstartSend a document for signature in four calls, with curl or the Node client. Node client@signsealer/sdk: no dependencies, retries with idempotency keys, the API's own error sentences. AI assistants (MCP)Connect Claude, ChatGPT, Codex or your editor, and send and check documents by asking. Templates and versionsCreate, publish and revise the text people sign, over the API, with every version kept. Signing inside your productThe signing page in a frame on your own site, and the events it sends you. Waivers and workflowsA public form, a QR at the counter, a kiosk: people start their own document. Signing a PDFA lease with initials in the margin: the file kept whole, the boxes on the page, the signed copy still theirs. Reservations and packetsSeveral documents about one booking, several people, one link, one ready state. WebhooksSigned events with a retry ladder, so your system hears back without polling. Platforms and partnersEmbedding signing in your own product, and sharing in the revenue of every business you bring.

How it fits together

  your application ──── POST /v1/documents ──────▶  SignSealer API
        ▲                                                │
        │                                    mints one link per signer
        │                                                │
        │                              email · text · QR · kiosk · your own message
        │                                                │
        │                                                ▼
        │                                           the signer
        │                                  reads · consents · answers · signs
        │                                                │
        │                                                ▼
        │                          append-only trail  +  certificate  +  sealed PDF
        │                                                │
        └──────── signed webhook: signing.completed ─────┘

Every arrow is in the reference. The signer's page is ours and loads no script; what your application sees is JSON in and a signed event out.

Recipes, by outcome

Send a signing request — template, publish, prepare, send.
Change a template people have already signed — revise, publish, and ask them to sign again.
Show the signing page inside your app — an embedded signer and a framed link.
Put a waiver behind a QR code or a link on your site — a public workflow.
Take waivers on a tablet at the counter — the kiosk.
Get every guest on a booking to sign before check-in — a packet with a ready state.
Handle a minor and a guardian — roles in a packet, the guardian judged on the day.
Download the evidence after signing — the package and the sealed PDF.
Verify a certificate — without an account, from the code and the document.
Hear when a document completes — and verify the event's signature.
Send and check documents from Claude, ChatGPT or Codex — the MCP server.

Done in the dashboard

Some things you will look for in the API are done by a person in the dashboard, and have no route. This is where each one is, and what the API sees of it.

What	Where	What the API sees
Sending one agreement to a list of people, from a CSV file or a pasted list: a column for the name, one for the email and one for each blank, up to 250 rows, and every row checked before any is sent.	Send to a list	A document for each row, each with its one signer, listed by `GET /v1/documents` and reported to your webhooks like any other. To send a list from your own system, prepare and send a document for each person.
The activity log: every send, void, setting changed and key issued in the account, in order and append-only, each entry sealed to the one before it and the newest re-checked when the page opens. Owners and admins see it unless a person's permissions say otherwise.	Activity	Nothing. No route reads it.
The words a signer reads: the signing request by email and by text, the reminder by email and by text, the confirmation by text, the signed copy, the renewal reminder and the link for somebody added to a booking, each in the business's own words with blanks such as `{{link}}`.	Messages	No route sets or reads them, and a send carries no wording of its own: whatever starts a document, its messages go out in the words set here.
Creating, changing and deleting a workflow: the template it runs, its roles (the participant, any fixed signers, and their order), how long a link lives, when to remind, its public address and its questions; and for a public address, its checks before it goes live, the email check and its limits (Waivers and workflows, "A signing link on your own website").	Forms & QR	`GET /v1/workflows` lists them, with `signer_roles`, `sequential`, `public_slug`, `email_check`, the link's limits (`stop_after_signed`, `closes_on`, `once_within_days`), `closed`, why a link takes no more signatures, and `needs_attention`, the check a live link fails. `POST /v1/workflows/{id}/start` starts one and `GET /v1/workflows/{id}/qr` draws its public address. No route creates, changes or deletes one.
Documents for bookings: which documents a booking owes and who signs each one, from which bookings, with a default for the rest. A connected booking system has its own on its page; the bookings sent through the API have theirs.	Documents for bookings	`PUT /v1/subjects` builds the packet from them, and `GET /v1/packets/{id}` shows who owes what (Reservations and packets). No route lists or changes them.

Whether SignSealer itself is up is not in the API either. status.signsealer.com shows it, and https://status.signsealer.com/status.json is the same as JSON, with no key, cached for a minute: all_operational, each component's state with ninety days of checks, and the incidents.

Ready to build? An API key takes a minute in the portal, and the free plan covers the first 10 agreements a month.

Get an API key