Versioning and deprecation policy

What we promise about /v1, how changes are announced, and what counts as breaking.

/v1 is additive-only

Within /v1 we may add: new endpoints, new optional query parameters, new fields on an existing response. We will not remove or rename a field, change a field's type, change an endpoint's URL, or change the meaning of an existing value.

So write clients that ignore unknown fields. A new field appearing is not a breaking change, and strict schema validation that rejects unknown keys will break on a change we consider safe.

What is not covered

Two things are deliberately outside the contract:

error.message is prose. Wording may change at any time. Branch on error.code, which is stable.

Ordering without an explicit sort. Each endpoint documents its default order and we don't intend to change it, but rely on sort= if the order is load-bearing for you.

If a breaking change is ever needed

It ships as /v2, alongside /v1 rather than replacing it. /v1 would then get a deprecation window with:

An entry in the changelog.
An email to accounts using the affected surface, if you have changelog notifications on.
A stated sunset date, not a surprise.

Nothing has been deprecated to date.

Recent changes worth knowing

Two changes landed on 2026-07-26 that were previously documented as planned:

The error envelope became coded. It was {"error": "message"}; it is now {"error": {"code", "message", "request_id"}}. Clients string-matching the old flat value need updating — this is why code exists.
Slug addressing, sort= and include= went from documented-as-target to shipped.

Both were reconciled with the reference in the same change, so nothing in this documentation describes unshipped behaviour any more.

Game namespacing

/v1/{game}/{resource} is game-agnostic by construction. A second title extends the same paths rather than replacing them, so adding one is additive for you: your cs2 calls keep working unchanged.

A game that isn't onboarded returns 404 unknown_game — a clean answer, not an error.

Status and incidents

Availability, incident history and planned maintenance are on the status page. See status and support.