Changelog & deprecations

This page records how the API is versioned, what counts as a breaking change, how deprecations are signalled, and the log of changes to each version.

​

Versioning

The API is versioned in the URL path (/v1, and a future /v2). There is a single global version across the whole API — not a separate version per resource — and no header- or date-based versioning.

​

Additive changes don’t bump the version

The following are made within the current version, and your integration must tolerate them:

• adding new endpoints
• adding new optional fields to a response
• accepting new optional request parameters or new values in an input enum

Build clients that ignore unknown response fields so additive changes don’t break them.

​

Breaking changes ship in a new version

A new version (/v2, …) is introduced only for changes that could break an existing integration, such as:

• removing or renaming a field
• changing a field’s type
• removing a previously accepted input value
• changing default behavior or tightening validation

​

Deprecation policy

When a version is scheduled for retirement, responses from it carry two standard headers: Both are machine-readable, so you can detect a deprecation in your monitoring. A deprecated version is supported for at least 12 months from the date its successor ships before it is sunset, giving you a long, predictable window to migrate.

​

Changelog

​

v1 — pre-release

• Initial pre-release of the read-only v1 API: vaults, balances, transactions, addresses, networks, and assets.