Skip to main content

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.

The Hasp AI API version is 2026-04-01. 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-059.

​
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 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.

​
API versioning

The current version is 2026-04-01. Breaking changes that cannot be phased in incrementally will ship under a new version prefix (/v2/*). The v1 surface will remain active per the overlap timeline above. There is no Api-Version request header — version selection is via URL prefix. This keeps routing explicit and tooling simple.

​
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.