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.
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.