API versioning and deprecation policy

What can change in the Aback Launch API, how you will hear about it, and how long you have.

Versions

The major version is in the path: /api/v1. It is the only version, and it is current.
Within v1, changes are additive only: new endpoints, new optional parameters, new fields in a response, and new error codes.
A breaking change (removing or renaming a field, changing a type, tightening validation) ships as a new version, /api/v2, and v1 keeps answering until its sunset date.
The MCP server follows the same rules for its tools and their arguments.

Write clients that ignore fields they do not know, and branch on the error code, never on the message text.

Every API response carries Link: <https://abacklaunch.com/developers/versioning>; rel="deprecation", pointing here (RFC 9745).
A deprecated path also answers with a Deprecation header, the date it was deprecated (RFC 9745), and a Sunset header, the date it stops answering (RFC 8594). Its replacement, when there is one, is linked with rel="successor-version".
The Sunset date is at least 180 days after the Deprecation date.
Every deprecation is listed on this page and in the changelog, and the OpenAPI description marks the operation as deprecated.

None. Nothing in v1 is deprecated.

One field is kept only for older clients: error in the error object. Read code and message instead; error stays for as long as v1 does.