Crevio versions its API in the URL path, and never removes anything without announcing it in the response itself. An integration written against /v1 today keeps working; when something is on its way out, the responses tell you before the docs do.
The version is in the path
Every REST endpoint lives under a version prefix:
There is one live version, v1. The MCP server and the @crevio/sdk client speak the same version — the SDK pins it for you.
What is a breaking change
We treat these as breaking, and they only ship in a new version prefix:
- Removing an endpoint, a field, or an enum value
- Renaming an endpoint, a field, or an
operationId
- Making an optional request field required, or narrowing an accepted type
- Changing the type or meaning of an existing response field
- Removing or repurposing a webhook event
These are not breaking, and can ship to v1 at any time — write clients that tolerate them:
- Adding a new endpoint, an optional request field, or a response field
- Adding a new enum value to a field already documented as extensible
- Adding a new webhook event type
- Changing the wording of an error
message (the type and code are stable)
- Changing the ordering of results where no order is documented
Ignore response fields you do not recognise rather than failing on them. The
SDK already does this.
How a deprecation is announced
When an endpoint or field is scheduled for removal, every response from it carries two standard headers:
The guarantee: at least six months between Deprecation and Sunset, and the replacement is live and documented before the Deprecation header appears. Nothing is removed without both headers having been served for that whole window.
Agents and long-running integrations should log the presence of a Deprecation
header and surface it. It is the only warning you get that is delivered in-band.
Checking programmatically
No output means nothing you are calling is scheduled for removal.
Machine-readable surfaces
The OpenAPI description marks a deprecated operation or field with "deprecated": true before the header ever appears, so a generated client can warn at build time:
