> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Compatibility Policy

> Additive-first versioning, tolerant reader contract, 6-month notice and 12-month overlap for breaking changes.

The HASP AI API version is `2026-07-12`. This document defines what changes are considered breaking, how breaking changes are communicated, and the support timeline you can depend on.

## What is stable

Once a route, parameter, or response field ships in a released API version, the following are guaranteed:

* **Route paths** — `/v1/ai/chat`, `/v1/messages`, and all other `v1/*` paths will not change or disappear.
* **Request parameters** — documented parameters will not be renamed or removed.
* **Response fields** — documented fields will not be removed or have their types changed in an incompatible way.
* **Error codes** — documented `hasp_code` values are frozen. New codes may be added; existing ones will not change meaning.
* **HTTP status codes** — documented status codes for documented error conditions will not change.
* **`request_id` format** — the `req_<ulid>` format is frozen per [ADR-SFKDZP](/ai-api/concepts/identifiers).

## What is additive (non-breaking)

The following changes are **not** considered breaking and may be deployed without advance notice:

* Adding new optional request parameters.
* Adding new response fields.
* Adding new error codes.
* Adding new SSE event types.
* Returning richer error detail in `hasp_details`.
* Adding new endpoints to the `v1` surface.

**Adopt a tolerant reader policy:** ignore fields you don't recognize, don't fail if a response includes unexpected properties.

## What is breaking

The following require the full deprecation timeline:

* Removing or renaming a documented request parameter.
* Removing or renaming a documented response field.
* Changing the type of a response field.
* Changing the HTTP method of an endpoint.
* Changing the semantics of an existing error code.
* Changing the `request_id` format.

## Deprecation timeline

1. **Announcement** — 6 months before removal, an entry is added to the [Changelog](/ai-api/changelog) and a deprecation notice is added to the reference docs.
2. **Overlap period** — for 12 months, both the old behavior and the new behavior are available. The old behavior may require an opt-in header or a versioned path.
3. **Removal** — after the overlap period, the deprecated behavior is removed.

For model version deprecations, see [Model Selection → Deprecation Policy](/ai-api/concepts/model-selection#deprecation-policy).

## API versioning

The current dated version is `2026-07-12`, selected per request with the `Hasp-Version` header or per key with `pinned_api_version`, and echoed back on the `Hasp-Version` response header. See [Versioning](/ai-api/concepts/versioning) for the full resolution order and the pinned-version guarantee.

Breaking changes that cannot be phased in incrementally ship under a new version prefix (`/v2/*`). The `v1` surface will remain active per the overlap timeline above.

## Anthropic-compat surface

The compat surface (`/v1/messages`) tracks Anthropic's own wire format for the subset of parameters HASP supports. Parameters not in HASP's supported set return `UNSUPPORTED_PARAMETER`. As Anthropic adds parameters to their API, HASP will evaluate each for compatibility with the compliance substrate before exposing it.

The Anthropic-compat surface does **not** guarantee to track every future Anthropic API change. It is a compatibility shim for migration, not a full Anthropic proxy.