Skip to main content
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: