Digitalyser.io for developers
Operations

Versioning and deprecation

What we may change without warning, what we may not, and how much notice you get.

Publishing an interface is a promise about the future. Here is exactly how far ours goes.

The contract

The REST facade is versioned in its path: /v1. Within a version, changes are additive only.

We may add, without notice:

  • a new field to a response;
  • a new optional parameter;
  • a new capability, a new endpoint, a new value in a non-exhaustive enumeration.

Write your client so that these are not breaking changes: ignore fields you do not know, and do not assume a list of values is closed.

We will not, within a version:

  • remove or rename a field or a parameter;
  • change the type or meaning of an existing field;
  • change an identifier that was documented as stable;
  • make an optional parameter required.

Deprecation

A deprecation is announced in the changelog and stays available for twelve months. Deprecated surfaces keep working for that whole window — they do not degrade, they do not slow down, and they do not start warning in ways that break parsing.

There is no silent breakage. If we cannot honour that for a security reason, the change is announced as a security advisory with its own timeline, and it says why.

Current deprecations

None. As of 3 October 2026 nothing in the public contract is deprecated, so no removal date is running. A surface that appears here carries three things from the day it is announced: what is being retired, the date the twelve-month window opens, and the date it closes — which is the earliest day it can disappear.

SurfaceAnnouncedRemoval not beforeReplacement
No entry———

How you are told

Through the changelog, as a Deprecated entry, and through its two feeds: RSS and JSON Feed. That is the whole mechanism today.

We do not send the Deprecation and Sunset response headers (RFC 9745, RFC 8594), so a client cannot learn of a deprecation by inspecting responses. Subscribe to a feed, or watch the changelog. We would rather say this than let you wait for a header that never arrives.

Direct notice to the holders of a key — a message to the person who created the credential — is planned, and needs us to know who holds which credential first. Until then, the feeds are the only channel.

MCP protocol revisions

The MCP protocol itself changes on a cadence we do not control — the July 2026 revision removed SSE resumption, and that is why we serve Streamable HTTP only. We track revisions, we announce the ones that affect clients, and we do not adopt a revision that would silently change what a connected agent is allowed to do.

Was this page helpful?

On this page