# 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](https://status.signsealer.com), with ninety days of history. The Node client keeps its own changelog, in the package.

## Changes

Also as a feed: [changelog.xml](https://signsealer.com/docs/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](https://signsealer.com/docs/authentication).
- **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](https://signsealer.com/docs/branding).
- **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](https://signsealer.com/docs/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](https://signsealer.com/docs/templates#signer-blanks).
- **A Python client.** `signsealer` for Python, with the Node client's retries, idempotency keys and errors, and `verify_webhook`. [Python client](https://signsealer.com/docs/python).
- **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](https://signsealer.com/docs/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](https://signsealer.com/docs/partners#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](https://signsealer.com/docs/templates#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](https://signsealer.com/docs/pdf).
- **A webhook registered by its address.** `PUT /v1/webhooks` makes one endpoint per address, however often it is called. [Webhooks](https://signsealer.com/docs/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](https://signsealer.com/docs/sdk).

### 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](https://signsealer.com/docs/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](https://signsealer.com/docs/signers).
- **`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](https://signsealer.com/docs/signers).
- **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](https://signsealer.com/docs/pdf).
- **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](https://signsealer.com/docs/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](https://signsealer.com/docs/signers).

### 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](https://signsealer.com/docs/api).
- **New guides:** [Signers, roles and order](https://signsealer.com/docs/signers), [Your own signing page](https://signsealer.com/docs/signing-page), [Teams, roles and sign-in](https://signsealer.com/docs/teams), [Retention and redaction](https://signsealer.com/docs/retention), [Branding and domains](https://signsealer.com/docs/branding) and the [WordPress plugin](https://signsealer.com/docs/wordpress); and sections on [questions and fields](https://signsealer.com/docs/templates#fields), [the partner API](https://signsealer.com/docs/partners#partner-api), [which version of the Node client added what](https://signsealer.com/docs/sdk#versions), [limits on signing links](https://signsealer.com/docs/limits#signing-links), [getting the tablet app](https://signsealer.com/docs/kiosk#get-the-app) and [what is done in the dashboard](https://signsealer.com/docs#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](https://signsealer.com/docs/signers).
- **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](https://signsealer.com/docs/sdk#versions).
- **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](https://signsealer.com/docs/retention).
- **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)](https://signsealer.com/docs/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](https://signsealer.com/docs/api#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](https://signsealer.com/docs/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](https://signsealer.com/docs/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](https://signsealer.com/docs/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](https://signsealer.com/docs/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](https://signsealer.com/docs/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](https://signsealer.com/docs/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](https://signsealer.com/docs/limits).
- **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](https://signsealer.com/docs/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](https://signsealer.com/docs/limits).
- **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](https://signsealer.com/docs/limits).
- **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](https://signsealer.com/docs/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](https://signsealer.com/docs/sdk).
- **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](https://signsealer.com/docs/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](https://signsealer.com/docs/evidence).

### 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](https://signsealer.com/docs/pdf).
- **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](https://signsealer.com/docs/texting).

### 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](https://signsealer.com/docs/evidence).
- **A partner is reviewed before it earns.** `GET /v1/partner` says `review` (`pending`, `approved` or `declined`), `earning` and `earning_since`. [Platforms and partners](https://signsealer.com/docs/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](https://signsealer.com/docs/pdf).
- **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](https://signsealer.com/docs/kiosk).
- **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](https://signsealer.com/docs/pdf).

### 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](https://signsealer.com/docs/pdf).
- **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](https://signsealer.com/docs/evidence).

### 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](https://signsealer.com/docs/templates).
- **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](https://signsealer.com/docs/embedding).
- **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](https://signsealer.com/docs/limits).
- **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](https://signsealer.com/docs/authentication).
- **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](https://signsealer.com/docs/templates).
- **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](https://signsealer.com/docs/api) beside what it added, and the Node client's changelog lists every one it exposed.

[This page as Markdown](https://signsealer.com/docs/changelog.md) Ask an AI about it: [ChatGPT](https://chatgpt.com/?q=Please%20read%20https%3A%2F%2Fsignsealer.com%2Fdocs%2Fchangelog%20and%20explain%20it%20to%20me%20as%20a%20developer%20adding%20SignSealer%20to%20my%20application%3A%20what%20it%20covers%2C%20the%20calls%20involved%20and%20anything%20to%20watch%20out%20for.%20Use%20https%3A%2F%2Fsignsealer.com%2Fllms.txt%20for%20the%20rest%20of%20the%20docs%2C%20and%20cite%20the%20page%27s%20URL%20in%20your%20answer.) · [Claude](https://claude.ai/new?q=Please%20read%20https%3A%2F%2Fsignsealer.com%2Fdocs%2Fchangelog%20and%20explain%20it%20to%20me%20as%20a%20developer%20adding%20SignSealer%20to%20my%20application%3A%20what%20it%20covers%2C%20the%20calls%20involved%20and%20anything%20to%20watch%20out%20for.%20Use%20https%3A%2F%2Fsignsealer.com%2Fllms.txt%20for%20the%20rest%20of%20the%20docs%2C%20and%20cite%20the%20page%27s%20URL%20in%20your%20answer.) · [Perplexity](https://www.perplexity.ai/search?q=Please%20read%20https%3A%2F%2Fsignsealer.com%2Fdocs%2Fchangelog%20and%20explain%20it%20to%20me%20as%20a%20developer%20adding%20SignSealer%20to%20my%20application%3A%20what%20it%20covers%2C%20the%20calls%20involved%20and%20anything%20to%20watch%20out%20for.%20Use%20https%3A%2F%2Fsignsealer.com%2Fllms.txt%20for%20the%20rest%20of%20the%20docs%2C%20and%20cite%20the%20page%27s%20URL%20in%20your%20answer.) · [Google AI](https://www.google.com/search?udm=50&q=Please%20read%20https%3A%2F%2Fsignsealer.com%2Fdocs%2Fchangelog%20and%20explain%20it%20to%20me%20as%20a%20developer%20adding%20SignSealer%20to%20my%20application%3A%20what%20it%20covers%2C%20the%20calls%20involved%20and%20anything%20to%20watch%20out%20for.%20Use%20https%3A%2F%2Fsignsealer.com%2Fllms.txt%20for%20the%20rest%20of%20the%20docs%2C%20and%20cite%20the%20page%27s%20URL%20in%20your%20answer.) · [Grok](https://grok.com/?q=Please%20read%20https%3A%2F%2Fsignsealer.com%2Fdocs%2Fchangelog%20and%20explain%20it%20to%20me%20as%20a%20developer%20adding%20SignSealer%20to%20my%20application%3A%20what%20it%20covers%2C%20the%20calls%20involved%20and%20anything%20to%20watch%20out%20for.%20Use%20https%3A%2F%2Fsignsealer.com%2Fllms.txt%20for%20the%20rest%20of%20the%20docs%2C%20and%20cite%20the%20page%27s%20URL%20in%20your%20answer.)