Versioning and deprecation

Versions

The REST API and the webhook event envelope share one version string, currently 2026-08. It is the info.version of the OpenAPI description and the api_version field on every webhook event. Paths carry the major version (/v1).

What can change within a version

Changes within a version are additive only: new fields, new optional request parameters, new event types and new endpoints. Existing fields and endpoints do not change shape or meaning without a new version. Ignore fields you do not recognize, so additive changes never break your integration.

Deprecation and sunset

A breaking change ships as a new version, never as an edit to the current one. Removing a version, an endpoint or a field follows these steps:

1. The deprecation is announced in advance in these docs and the API Reference, with the date it takes effect.
2. From then on, every response that uses it carries a Deprecation header (RFC 9745) giving when it was deprecated, a Sunset header (RFC 8594) giving the date it stops working, and a Link header with rel="deprecation" pointing at the migration notes.
3. On the sunset date it is removed.

Check for these headers in your client logs to catch a deprecation early. Every API and MCP response, deprecated or not, also carries a Link header naming this page as rel="deprecation", beside the OpenAPI description as rel="service-desc" and the API docs as rel="service-doc" (RFC 8631).

Currently deprecated

Nothing. No version, endpoint or field of 2026-08 is deprecated.