Versioning and deprecation
How the API changes, how you're told, and how long you have.
Versions
- The major version is in the URL:
/v1. A new major (/v2) is introduced only for changes that can't be made compatibly, and/v1keeps running alongside it. - Within
/v1, every response carriesAPI-Version(for example1.1.0), the release that served it. The OpenAPI document'sinfo.versionmatches.
What we may change without notice
These are backwards-compatible. Write clients that tolerate them:
- Adding endpoints, optional request fields, response fields, enum values or headers
- Adding error
codevalues - Changing the order of fields in a response, or error message wording
- Tightening validation of input that was already documented as invalid
What needs a deprecation
Removing or renaming an endpoint, field or enum value, making an optional input required, or changing the type or meaning of a field. These follow the deprecation process and are never done in place.
Deprecation process
-
The endpoint is marked deprecated in the OpenAPI document (
deprecated: true,x-sunset) and in the reference. -
Its responses gain headers:
Deprecation(RFC 9745) is the date it was deprecated,Sunset(RFC 8594) is the earliest removal date, andLink rel="successor-version"points at the replacement. -
At least 6 months pass between deprecation and sunset (12 months for core CRM resources).
-
Organizations still calling it are contacted before the sunset date.
-
After the sunset date the endpoint may return
410 Gone.
Deprecated endpoints you still call
SalesOS records every call to a deprecated endpoint, per API key (or per
signed-in user for browser sessions). Settings → API Keys lists the ones your
organization called in the last 30 days, with the key, the call count and the
sunset date. The same data is at GET /v1/api-keys/deprecated-usage.
Currently deprecated
| Endpoint | Sunset | Replacement |
|---|---|---|
POST /v1/api-keys/{id}/regenerate | 2027-04-01 | POST /v1/api-keys/{id}/rotate |