Skip to main content
Every operation in the Trading API sits under the /api/v1 prefix. The major version in the path (v1) changes only when an incompatible change ships, and a new major version runs alongside the old one rather than replacing it in place. The spec’s info.version is currently 0.1.0. That semantic version tracks the spec document; the path prefix tracks the wire contract. Pin to the path prefix in your client.

​
What is a breaking change

A breaking change is anything that could break a conforming client: removing or renaming a field, changing a field’s type or units, tightening validation, or removing an endpoint. Breaking changes are announced in the changelog before they take effect. Watch it, and test against the next version before it lands.

​
What ships without a version bump

Additive, backward-compatible changes go out under the same /api/v1 prefix with no notice:
  • new optional request fields
  • new response fields
  • new endpoints
  • new enum values on fields the exchange already controls (for example, a new RequestAck status)
A client that ignores fields it does not recognize keeps working across all of these. Parse leniently: drop unknown JSON members instead of failing on them, and treat an unfamiliar status or error code as a rejection you do not yet handle rather than a parse error. The reader who hard-codes an exhaustive field list is the one who breaks on the next additive release.