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

# Versioning and stability

> Build against the API without watching for breaking changes: what we promise, what's in preview, and how the promise is enforced.

The API changes by adding, never by breaking. This page says exactly what that promise covers,
which parts are still in preview, and where the current baseline began. Read it before you decide
how tightly to bind your integration to a field.

## The additive-only promise

Everything in the API reference is additive-only from the current baseline, except the groups
marked as previews. Additive-only means a documented field or route never changes its meaning or
its type, and never disappears. We add new fields and new routes.

Your side of the promise is to ignore fields you don't recognize. In return, the fields you do
recognize keep working, and you never have to watch for a breaking-change announcement, because
there are none to watch for.

## What's in preview

A preview can still change shape, and it's outside the promise until its preview label comes off.

| Preview | Where it runs | What to expect |
| - | - | - |
| Challenges | Every Challenges operation is marked PREVIEW | Expect to revisit code you build against it |
| The venue routes, under `/api/partner/venues/{venueId}/…` | The sandbox today. Production access is arranged when your venue qualifies | Expect changes while the Preview label stays on |

The Legacy Partner API is under the promise: nothing in it is removed while a firm runs on it, and
[Keys and authentication](/api/keys) says which of its calls have venue routes. Partner routes and
`trdrs_sk_…` keys keep their current contracts. The `broker` query parameter keeps its spelling,
even though these docs call the thing it names a provider.

## Where the baseline began

The current baseline began on 2026-09-25, before the first partner integration. That day a reset
of an issued account became an audited operation on a settled account:
`POST /api/partner/accounts/reset` now requires the reason for the reset, and refuses while the
account holds a position, a working order, a command with an unknown outcome, unresolved risk or a
negative balance. It never closes or cancels anything itself.

That was a breaking change, so the baseline moved rather than the promise bending. No client or
integrator used the route, so there's no compatibility path, and the [changelog](/api/changelog)
says exactly what a test client written before then must change.

Earlier baselines:

| Began | Why |
| - | - |
| 2026-09-06 | The account stream was reshaped. The `snapshot`, `positions` and `orders` events were removed, and the whole account now arrives as one `account` event |
| 2026-08-29 | Connect removed its draft `handover` request field and `emailSent` response field |

## How the promise is enforced

The promise is checked on every build, not just stated. The build reads the engine's own router and
fails if a route a key can reach is missing from the reference, and every documented schema is
checked against the types the engine itself compiles against. A shape can't drift from what's on
the wire, and a route can't ship undocumented, without the build failing.