DevelopersDocsConcepts

Versioning

The AOS-Version header, how your account is pinned to a dated version, what counts as a breaking change, and how to upgrade safely.

The API is versioned by date. The current version is 2026-12-01.

#Your pinned version

The first time you make a key, your account is pinned to the version current that day. Every call without an AOS-Version header behaves as that version. A new release never changes how your integration behaves unless you ask for it.

To try a newer version on one call, send the header:

curl https://adv.heliosynctech.com/api/v1/cases/SBXX010000012026 \
  -H "Authorization: Bearer $AOS_KEY" \
  -H "AOS-Version: 2026-12-01"

An unknown version returns 400 with unknown_version. GET /account shows your pinned version as version.

#What can change without a new version

We add these at any time; write your code to ignore what it does not know:

  • New endpoints.
  • New optional request fields and new response fields.
  • New values in lists such as event types or error codes. Handle an unknown code by its type.
  • New headers.
  • Changes to the text of message. Branch on code.

#What needs a new version

  • Removing or renaming a field, an endpoint or an error code.
  • Changing the type or meaning of a field.
  • Changing what an existing call is billed for.

A breaking change ships as a new dated version. The old version keeps working. We list every version in the changelog, with what changed and how to move.

#Upgrade in four steps

  1. Read the changelog entry for the new version.
  2. Send AOS-Version: <new date> from your test key and run your tests against the sandbox.
  3. Fix what the entry says changed.
  4. Send the header from your live key, or ask for your account's pin to be moved.

SDKs and the CLI send the version they were built for. See SDKs.