Changelog and versioning

What v1 promises, and what has changed inside it.

What v1 promises

• Nothing is removed or renamed inside v1. A route, a field in an answer, a value of a field that is an enumeration, an error code: once published, it stays.
• Things are added. New routes, new optional request fields, new fields in answers and webhook bodies, new values of a field that is an enumeration (a status, an event type, an error code), new webhook events (sent only to endpoints that subscribe to them or to *). Write your client to ignore what it does not know, and to treat a value it has not seen as something it does not handle rather than as an error.
• A refusal may become more specific — a 422 whose message names more precisely what was wrong — but not a success into a refusal, except under the security exception below.
• A change that would break a client gets a new version, and v1 keeps working beside it for at least twelve months after the new one is published, with the date announced here and to every account's owner by email.
• The one exception is security. If keeping something working would leave a business's data or its signers exposed, we close it without a new version. The change is kept as narrow as we can make it and announced here, marked security; where possible whatever already worked is left working, and where something an account relied on does stop, its owner is told by email first.

Outages and incidents are on the status page, with ninety days of history. The Node client keeps its own changelog, in the package.

Changes

Also as a feed: changelog.xml (RSS).

5 November 2026

• A PNG signature is drawn on the sealed copy. A signature sent to /v1/signing-transactions as { method: "drawn", image }, or saved with /v1/signature-references and sent as { method: "saved", reference }, now appears as the picture it is in its box on the page and in the signer’s entry on the certificate, where the signer’s name was printed before. A PNG that is not well-formed base64, or whose header claims more than 8,192 pixels on a side or 16 megapixels, still prints the name. Nothing in the API changed. A copy sealed before today keeps the name.
• A damaged PNG is refused when it is sent. A PNG photo or logo whose pixels are not what its header says (cut short, a chunk that fails its CRC, data that does not inflate) is refused on the way in, saying it is damaged, rather than kept and left out of the sealed copy later. Export it again. A damaged PNG signature is still accepted, and its sealed copy prints the signer’s name.

3 November 2026

• The sandbox plays a signer. POST /v1/documents/{id}/signers/{signer}/simulate, for a test key, signs, declines or expires for them, through the signing page’s own checks, and the ordinary webhooks follow. Testing.
• The brand on every plan. GET /v1/branding answers the business’s own name, colors, dark logo and opening picture whether or not white label is on; whiteLabelEnabled now says only whether to leave SignSealer’s name off. Branding and domains.
• The back of an ID. ID evidence may be of the back of the card as well as its front: kind: "id_back" on POST /v1/sign/{token}/id-evidence, and id_back on its GET. A new value of kind, as v1 allows.
• An integration prompt for a coding agent, and each docs page as Markdown or asked of an AI. Integration prompt.
• Both ways of sending. A business that chooses Both under How documents reach people has SignSealer send what it sends from the dashboard, and gets back the links of what its own system sends through the API: on POST /v1/documents/{id}/send a signer with no delivery is then embedded, and delivery: "send" still has us send that one. Any other business is unchanged.
• Texts through the business’s own Twilio or Telnyx account. Connected on Messaging & numbers, a business’s texts go from its own number through its own account, billed by its provider. Nothing in the API changes.

2 November 2026

• A blank the signer fills in. A template question with "blank": true fills the blank of the same name in the text: a send may leave it out of values, the first signer answers it, and their signature writes it in before the text is fingerprinted. A blank the signer fills in.
• A Python client. signsealer for Python, with the Node client's retries, idempotency keys and errors, and verify_webhook. Python client.
• Signers can ask about a document. Where a business switches it on, a signer asks a question under Help me understand on the signing page and is answered from the document's words. Nothing in the API changes. Signing a PDF.

1 November 2026

• Who texts a partner's signers. PUT /v1/texting/sender with partner or none stops SignSealer texting the signers of documents your app sends, while email and webhooks go on; GET /v1/account says which applies in texting.sender. Partner texting.

31 October 2026

• Five more kinds of question. money, vin, ssn_last4, postal_code and percent, each checked as it is typed and found on an uploaded PDF by its label. A new value of kind, as v1 allows. Questions and fields.

28 October 2026

• A document from a PDF over the API. POST /v1/documents/from-pdf takes the file and its boxes, or finds them from text tags in its words, each box for the signer whose sign_order is its recipient; a send that leaves a recipient's boxes with nobody is refused with 422. Signing a PDF.
• A webhook registered by its address. PUT /v1/webhooks makes one endpoint per address, however often it is called. Webhooks.
• An application vouches for its own people. /v1/signing-applications, /v1/signature-references and /v1/signing-transactions: your server signs an approval with its own key and the signing is recorded as authenticated by your application. Node client.

24 October 2026

• Every start is counted as a send is. A workflow started from the API, a packet's next item and a party member added are refused with 402 quota_exceeded when the business cannot take another signing: its ten free signings for the month used on Free, a balance that does not cover the next one, its own spending limit, or a stopped subscription. Before, only a send was refused, so a start that once succeeded can now be refused; it is the security exception above, for a fault that let signings be taken past what the business pays for. A tablet's capture made with no network is answered 429 allowance_reached instead, and kept to send again. Errors.

22 October 2026

• A document each for a party. party_documents on GET /v1/workflows: one, the document the whole party signs, as before; or each, a document for every adult the person who booked adds, made from the first, with their own name in it. Each completes on its own and each is a signing. The links that come back from POST /v1/sign/{token}/party, the party link and party on a signing link work across them all. Signers, roles and order.
• persons under fields starts a party as it does under values, so a start that fills in asked_fields can add it beside them.

15 October 2026

• The business signs its own line. A signer sent with for_business: true on POST /v1/documents/{id}/send (or by an assistant, with signsealer_send_document), or a workflow's fixed role with business: true, signs for the business. The template's questions with supplied_by: "business" are theirs and nobody else's, and they are asked nobody else's. On an uploaded PDF, the business's own signature line, its date and its name are found at upload and made such questions, so each box on the page has one person's answer. Each link answers for_business. Signers, roles and order.
• An uploaded PDF’s boxes are placed for it. A PDF uploaded in the dashboard has its signature and date put where the file asks for them, and every other line, box to tick, box to write in and fillable field added as a question on its own box, named by the words beside it, for the business to check before it publishes. Text in square brackets is never a box: every piece is highlighted on its page and listed, to replace before the file is sent or, where it is meant to be there, to keep as part of the document. GET /v1/templates/{id} shows them as any placed question, with a place. Signing a PDF where it is.
• The party over the API. The person who booked adds the others in their party with POST /v1/sign/{token}/party, as the signing page lets them: each person with an address is sent their own link, anybody we could not send it to comes back with theirs for you to hand over, and party_link is where a place kept open is taken from. POST /v1/sign/{token}/party/share makes the party link again and POST /v1/sign/{token}/party/link one person’s link. Your own signing page.
• A link goes when it is its signer’s turn. On a document prepared with sequential: true, or a workflow signed in order, only the first step is sent its links. A later step’s signer is held, and is sent a new link of their own when everybody before them has signed. POST /v1/documents/{id}/send and POST /v1/workflows/{id}/start answer token: null and url: null with held: true for a held signer, where they answered a link that the signer could open only to be told to wait; and POST /v1/documents/{id}/signers/{signer}/remind refuses one with 422 until their turn. An embedded signer is not held, nor is anybody when the business sends its own links. Signers, roles and order.

7 October 2026

• The reference shows more. Each route's query parameters, the fields inside a list (signers[].email, participants[].full_name), and the OAuth and partner endpoints, drawn from the same declarations as /openapi.json. Nothing about the API changed. API reference.
• New guides: Signers, roles and order, Your own signing page, Teams, roles and sign-in, Retention and redaction, Branding and domains and the WordPress plugin; and sections on questions and fields, the partner API, which version of the Node client added what, limits on signing links, getting the tablet app and what is done in the dashboard.
• A copied recipient is sent the signed copy. A signer with role: "cc" and an email address is emailed the sealed PDF when everybody else has signed, as the send screen always said and as nobody was. They are still sent no link, no reminder and no text, and asked nothing. Signers, roles and order.
• The Node client on Node 18. Before @signsealer/sdk 1.11.1, every write not given its own idempotency key threw on Node 18 unless it was started with --experimental-global-webcrypto. Node client.
• A redacted document names nobody, and reads as intact on the list. GET /v1/documents answered integrity_ok: false for every redacted document with a signature, where GET /v1/documents/{id} answered true; both now check its signatures against the fingerprint it kept. A redaction now also takes out the name of each child an answer was about (answers[].about reads Redacted child 1 and so on, and so does a parent or guardian's statement), the dates of birth a party gave, and the document's link to the person on file it was about (subject_party_id and subject_name read null), on documents redacted before today too. And a redacted document's certificate now verifies (still_matches_record: true) in two cases where it could say the record had changed: when signers shared a place in the order, as a party's do, and when a question had been shown or hidden by an earlier answer. Retention and redaction.
• Corrections. These pages said otherwise, and the API has always done this: under a location require, a signer who declines is recorded and the signature is still refused; a signer's one-time code is paced with 422 invalid, not 429; the four parts of signing:write are held by a connected app's tokens, and a dashboard key takes signing:write whole; a workflow role with "self": true cannot be set through the API; a staff field can be placed on a PDF's page, filled by the sender.

6 October 2026

• An MCP server. POST https://api.signsealer.com/mcp is a remote Model Context Protocol server that Claude, ChatGPT, Codex and the coding editors connect to with OAuth: ten tools, each the same check and the same work as the /v1 route that does the same thing. It answers protocol version 2026-07-28, which has no handshake, and 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05, opened with initialize. AI assistants (MCP).
• An app can register itself. POST /oauth/register takes an RFC 7591 registration naming redirect_uris, as an MCP client sends the first time it meets SignSealer; the server describes itself at /.well-known/oauth-protected-resource/mcp (RFC 9728) and /.well-known/oauth-authorization-server (RFC 8414). Such an app may be given reading and the four parts of sending below, no more, and is removed if nobody connects it within a day. OAuth.
• Four scopes inside signing:write. signing:send, signing:remind, signing:links and signing:void each allow one part of what signing:write allows, so a person connecting an app can let it send without letting it void. signing:write still allows all four, and every route that takes one says so. Authentication.
• Connecting again with less ticked takes it away now (security). Leaving a box clear when an app is connected again narrows the access tokens it already holds at that moment, where a token issued before kept its scopes until its hour ran out; a token left with nothing is revoked. Moving a connection to signing:write, which holds the four parts, takes nothing away. Authentication.
• Refresh tokens only for an app that asks. An app that registers itself without naming refresh_token in grant_types is given no refresh token, where it was given a thirty-day one anyway. WordPress sites, partners and apps already registered keep what they had.
• The docs as Markdown. Every docs page is also served as Markdown at its own address with .md (/docs/quickstart.md), and all of them together at /llms-full.txt, for a coding assistant to read whole.

3 October 2026

• A signer's position goes only where it is named (security). signing.location_shared, which carries the latitude and longitude a signer shared, is sent only to an endpoint that names it; an endpoint on "*" is no longer sent it, and no event reaches "*" with a position in its detail. That is a delivery "*" used to receive and now does not, made under the security exception: a webhook goes to whatever address was typed, often somebody else's tool, and where a person stood is not something to send there unasked. Endpoints are unchanged and nothing is deleted; a position already waiting in such an endpoint's queue is not sent, and replaying one it was sent before is refused with 422. Add signing.location_shared to an endpoint's events to keep receiving it. Webhooks.
• Six more events can be named. signing.verified, signing.id_captured, signing.photo_supplied, signing.link_shown, signing.location_shared and signing.location_declined are taken by POST /v1/webhooks, where they were refused; "*" was already sent all of them but the position. Webhooks.
• signing.delivered is sent. When the email carrying a signer's link reaches their mail server, with detail.channel email, and, for a business that turns it on, when the phone network says a texted link reached the phone, with sms: once per signer per channel, and only while the document waits for them. It was listed and never sent. Neither means the message was read; signing.viewed still says it was opened. Webhooks.
• A change to an endpoint's events is checked. PATCH /v1/webhooks/{id} refuses an events name that is not an event with 422, as POST /v1/webhooks always has, and the hint lists every event. It once stored the name, which then never arrived, so this turns a success that did nothing into a refusal that says so. A change that sends no events goes through as before, and a name stored earlier is kept and listed in unknown_events on GET /v1/webhooks. Webhooks.
• One reminder by text (security). A signer is texted at most one reminder over the life of their link, because the words they agreed to say "at most one reminder"; the dashboard's, the API's, the automatic one and a party's link sent again all count. After it, POST /v1/documents/{id}/signers/{signer}/remind sends the reminder by email alone (by: "email"), and for a signer with no email address it is refused with 422, where it once texted them again. Limits and paging.
• A busy photo is a 429. The two photo routes on a signing link answer 429 busy with Retry-After when the photo was not read because others were being read, where they answered 422 invalid. Nothing was kept; send the same photo again after that long. Errors.

2 October 2026

• How many people a business sends to (security). Signing links are counted against a ceiling an hour and a day that grows with how far the business is trusted, and a send, a workflow start or a public form past it is refused whole with 429 rate_limited and Retry-After, where it once went through. A business's signers are sent at most three hundred codes by text an hour between them. Limits and paging.
• Reminders (security). POST /v1/documents/{id}/signers/{signer}/remind is refused with 422 past three reminders to one signer in a day, or twenty-five for one document, counting the dashboard's and the automatic ones.
• Every message is screened before it leaves (security). A message to somebody outside the business may be held for review or not sent; the API's answers are unchanged, and nothing in the API says so yet. Limits and paging.
• A partner's connection is the person's who made it (security). It ends when that person is removed, leaves, or can no longer give what it holds, and a refresh is refused with invalid_grant from then. Authentication.
• The signing day a tablet keeps (security). captured on POST /v1/sign/{token} is kept only when a paired tablet of the link's business sends its own credential with it; from anybody else it is left out, and the signature is dated when it arrives. The certificate's network region is read only from requests that crossed our edge. Node client.
• An answer after the end (security). POST /v1/sign/{token}/fields is refused once the document is voided, declined or expired or the link is past its date, as a signature is; six hundred answers an hour per link.
• Photos are checked before they are read. The two photo routes on a signing link refuse a link that would not keep a photo before decoding it, read one photo per link at a time, and answer 422 asking to send again when the photos waiting to be read are queueing.
• A webhook's body is let go. Once a document is redacted, or a finished delivery is older than the business's message retention, the people are taken out of its stored body, and a replay sends it that way. Webhooks.
• Everyone in the party signs. A workflow can have each person in a booking's party sign (each_person_signs on GET /v1/workflows); its start answers party_size, and the signing link carries party: who is still to be added, and who was. The person who booked adds them on the signing page. Each person with an address we may write to is sent their own link, a link the booker handed over is assured as party_link, and party links are made on the business's own signing host. Evidence and certificates.

1 October 2026

• The pages a signer reads are drawn from the file they sign. SignSealer draws an uploaded PDF's pages itself; drawn on GET /v1/templates/{id}/pdf counts only those, and a signing link shows no other. Signing a PDF where it is.
• Times say which clock they are on. POST /v1/documents takes time_zone; a time blank is written in words with the zone named, and the signing link says time_zone.

29 September 2026

• Whether a business can text. GET /v1/account says texting: available, why_not (plan when its plan has no texting, number while it waits for its own verified texting number, beta while the business is in the beta, which does not text, test for a sandbox) and wording, the opt-in sentence to put beside a "text me" box and record with POST /v1/sms-consents when it is ticked. Texting and consent.

28 September 2026

• The signed copy is sealed once. GET /v1/documents/{id}/pdf returns the copy sealed when the document completed, the same bytes on every call. GET /v1/verify/{code}?sha256= takes the SHA-256 of that file as well as of the document's text: copy_matches says it was the file, and document_matches is true for either. Evidence and certificates.
• A partner is reviewed before it earns. GET /v1/partner says review (pending, approved or declined), earning and earning_since. Platforms and partners.
• Reminders. POST /v1/documents/{id}/signers/{signer}/remind is refused with 422 when nothing could be sent — an address we may not write to, and a number that cannot be texted a reminder — and the link the signer holds keeps working; by in its answer is the channel the reminder went by.

27 September 2026

• A name is only a name (security). POST /v1/workflows/{id}/start refuses a full_name with a web address in it with 422, where it once accepted one: the name is printed in the signing email, and a web address there is a link somebody else chose.

26 September 2026

• The signing date is the day it was signed. {{date}} and its synonyms (today, signed_on, date_signed and the rest) are never supplied: a value sent for one on POST /v1/documents is ignored, and the first signature writes that day in, in the business's timezone. Signing a PDF where it is.
• The signing day is nobody's to choose (security). captured on POST /v1/workflows/{id}/start is refused with 422 from anything but a paired tablet, where it was once accepted from any key and let the caller choose the day a document says it was signed. A tablet's date is kept only when it is within a day of the tablet's own clock and not after today. Tablets and kiosks.
• Times and periods. A question can be a time or a datetime; what is picked is written into the document in words, and a period whose end comes before its start is refused.
• Boxes the sender fills in. A question marked staff and placed on an uploaded PDF is given when the document is sent, under values on POST /v1/documents, or fields or values on a workflow start; a required one that is missing refuses the send. The signing link's fields say from_sender, and placed_words gives a placed date or time as it is printed on the sealed copy. Signing a PDF where it is.

25 September 2026

• Boxes signing fills. A signature box or signing-date box placed on an uploaded PDF is filled by signing itself; the signing link's fields say at_signing and placed_value, and signing no longer refuses for those boxes. Signing a PDF where it is.
• The photographs in the signed copy. The sealed PDF and the bundle print each photograph taken as an answer after the certificate, with its SHA-256. settings.photos_in_copy on a template, and on PATCH /v1/templates/{id}/settings, turns it off. Evidence and certificates.

24 September 2026

• Templates, all the way through. GET /v1/templates/{id} (the version whole, with every version of its code), PATCH /v1/templates/{id} (change a draft), POST /v1/templates/{id}/publish, POST /v1/templates/{id}/revise, DELETE /v1/templates/{id} (a draft) and PATCH /v1/templates/{id}/settings. GET /v1/templates takes code. Templates and versions.
• Signing inside your product. A signer sent with delivery: "embedded" is sent nothing; POST /v1/documents/{id}/signers/{signer}/embed mints a link to frame; the signing page and public forms may be framed on the business's proven sites and post what happened to the page around them. GET /v1/account says frame_origins. Signing inside your product.
• Your own reference. POST /v1/documents takes external_ref, metadata and return_url; webhooks carry them back; GET /v1/documents?external_ref= finds them; the list and the document say them.
• Reminders. POST /v1/documents/{id}/signers/{signer}/remind.
• Paging. GET /v1/documents answers total, has_more, limit and offset.
• Rate-limit headers on every keyed answer. Limits and paging.
• The signing and verifying routes answer a browser on another site (CORS), so a signing page of your own can call them directly.
• The send's answer carries each link's url and delivery.
• The OpenAPI description types each path parameter (a signing token is not a UUID), declares query parameters, says 201 where a route makes something, documents 409 template_changed and the OAuth endpoints, and files every operation under a declared tag.
• Test keys. mk_test_ keys act on the business's sandbox, where nothing is sent to anybody and nothing is billed; GET /v1/account says mode. Testing.
• A template's history. POST /v1/templates/{id}/restore brings an older version back as a new draft; change_note on PATCH and revise, and on each of versions with its name, date, file and documents. Templates and versions.
• Tablets (security). A tablet paired from now on starts at gate: "own": it shows a signing link only for a document it started itself, and asking it for one it did not start is refused with 403, which it would once have answered. That is a success becoming a refusal, made under the security exception above: a tablet's key could otherwise open a signing link for any unsigned customer in the account, and the certificate would still have called it an emailed link. Tablets paired earlier were left at account, so nothing that worked stopped working, and an owner can set either under Apps & tablets or with PATCH /v1/devices/{id}, which takes gate; GET /v1/devices says it, and GET /v1/documents/{id}/signers answers link_allowed.
• A WordPress site's own connection (security). The OAuth client the plugin registers for its site no longer carries signing:templates, which the plugin never used; asking for it grants the rest, and the token's scope says what was granted. Connections already made keep what they were given. A client we registered for a partner is unchanged.

Before

Earlier changes were recorded by the migration that made them rather than here; each is named in the reference beside what it added, and the Node client's changelog lists every one it exposed.

This page as Markdown Ask an AI about it: ChatGPT · Claude · Perplexity · Google AI · Grok