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 webhook events (sent only to endpoints that subscribe to them or to *). Write your client to ignore what it does not know.
• A refusal may become more specific — a 422 whose message names more precisely what was wrong — but not a success into a refusal.
• 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.

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

Changes

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.

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.