# API versioning and deprecation policy

> How the Aback Launch API is versioned, what can change within v1, and how a deprecation is announced: Deprecation and Sunset headers at least 180 days ahead.

Canonical: https://abacklaunch.com/developers/versioning

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.

## How a deprecation is announced

- 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](https://abacklaunch.com/changelog), and the OpenAPI description marks the operation as deprecated.

## Current deprecations

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.

## Related

[Aback Launch API docs](https://abacklaunch.com/developers), the [OpenAPI description](https://abacklaunch.com/api/v1/openapi.json) and the [MCP server](https://abacklaunch.com/developers/mcp).
