Changelog

Changes that affect integrators. Breaking changes are called out explicitly and never ship without notice — see How we version below.

Every page carries the build revision in its footer; quote it if you report something that looks wrong.

Unreleased

Known issues on the integration environments, being worked on. Listed here so you do not lose time to them.

• ?trading=true is not applied on GET /api/v1/markets. The response is identical with or without it. Filter on the trading field client-side — see Market status.
• WebSocket handshake requires X-prefixed headers. Sending the REST names connects the socket anonymously and fails later with unauthorized on a private channel, which reads like a key problem. See Integrate.

2026-08-25

First public release of these docs.

REST API

• 16 endpoints documented across Identity, Orders, Trades, Events, Markets, Account and Portfolio, generated from the OpenAPI document
• Interactive API console with a live Try it
• Postman collection with the Ed25519 signing script wired into the pre-request hook

Documented and verified against demo.stxapp.io

• price is whole cents, 1–99. A value above 99 returns 422 The order's price must be lower than 1.00 — the message states the cap in dollars, the field is cents
• POST /api/v1/orders takes a flat body and returns 200, not 201
• Collections return { cursor, <resource>: [...] }, not { data }
• Every /api/v1 route requires a signature; there are no public REST endpoints
• The signed path includes the query string

WebSockets

• All eight channels documented, with the snapshot each private channel pushes on join
• cancel_on_disconnect with an interactive demo
• The market_updates topic is plural; older docs show it singular

Concepts

• United States and Canada — two separate exchanges, different regulators, one API surface
• Market status — the seven stored statuses, and why a response can say suspended when you filtered for open

How we version

The REST API is versioned in its path (/api/v1). Within a live version we make only additive changes — new optional fields, new endpoints, new enum values. A client that ignores unknown fields will not break.

Anything that would break an existing client goes to a new version, and the old one keeps working through a stated sunset window. When an endpoint is deprecated you will see it three ways before it goes away:

• Deprecation and Sunset headers on the response itself
• deprecated: true in the OpenAPI document, which surfaces as a banner on the endpoint page
• an entry here, dated, ahead of the change

If you are integrating seriously, watch this page.