Versioning & deprecation
The version is in the path
This API is versioned in the URL path, and there is exactly one version: /v1.
Every operation lives under it — POST /v1/predict, POST /v1/predict/batch,
POST /v1/history and POST /v1/validate — and every operation added later. Your
integration pins the version by construction — nothing about a request opts into
behaviour it did not ask for.
POST /v1/validate is the validation endpoint for the scoring call: it returns a
verdict and carries none of the members a scored answer carries, so there is nothing
about it to version separately. Sending a body to /v1/validate tells you whether
POST /v1/predict would accept it.
Two paths sit outside the version prefix, and neither one is an operation.
The first is the MCP Endpoint at /mcp — a protocol doorway. Its tools
re-enter the current version's operations, so a connected agent always sees the
current shape of the answer.
The second is the sign-in discovery document, and it is the one an AI assistant reads
first, before it can connect to /mcp at all. It is served at
/.well-known/oauth-protected-resource and at the path-scoped
/.well-known/oauth-protected-resource/mcp. A firewall or proxy rule written from this
page must allow it alongside /v1 and /mcp: block it and assistant sign-in fails at
the first step.
What a breaking change looks like
A breaking change ships under a new version path — /v{n+1} — never inside the
one you are using — once the API has real integrations to protect. While it is
invite-only that is not yet the rule; the exception is spelled out in
While the API is invite-only below, and you should
read it before you rely on this paragraph. When a new version ships, the prior version
remains supported for a deprecation period of 90 days from the deprecation
announcement, so an integration has a full quarter to move at its own pace.
There is no second version path today and nothing is deprecated. No sunset date
stands against /v1, and no clock is running on anything you have built.
While the API is invite-only
Public signup is not open, and every API Key in existence was issued by hand to a
named holder. While that is true, a breaking change may land in place on /v1,
and every keyholder is told directly — before it happens, in a message addressed to
them — exactly which members changed and what to do about it. Direct notice to a list
short enough to read out loud is a stronger guarantee than a window nobody is
waiting on.
The version path and its 90-day window are what replace that notice the moment the list stops being short enough to read out loud: they apply from public signup onward, and to any integration we cannot notify individually. That is the policy, and it is written here so you can hold us to it.
Error types and statuses are part of the contract
The type URI and the HTTP status of every documented error are stable identifiers
you can branch on. They never change without a documented deprecation. Adding a
new error to the reference is an additive, safe change; renaming or
re-statusing an existing one is a breaking change and is treated exactly like one.
The same holds for the response schema: members are added, not repurposed. A member documented as absent-when means exactly that, and its absence rule changes only with a version.
Docs build: canary-2026-08-13-staging-tier.