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
codeby itstype. - New headers.
- Changes to the text of
message. Branch oncode.
#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
- Read the changelog entry for the new version.
- Send
AOS-Version: <new date>from your test key and run your tests against the sandbox. - Fix what the entry says changed.
- 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.