Releases

Release Notes

OpenMarket Data API documentation history: what each docs release covers, newest first, with links into full entries.

These notes describe published documentation for the OpenMarket Data API at https://api.openmarket.xyz, regional WebSocket endpoints, authentication, limits, and error behavior.

Releases are listed latest first.

Latest release

v1.0.1 — API hostname migration

July 2026 — Public REST and regional WebSocket hostnames now use openmarket.xyz, and REST authentication uses X-OpenMarket-Key. Existing kiyotaka.ai hostnames remain supported, with no confirmed shutdown date.

Full notes →

All releases

VersionDateHighlightsBreaking changes
v1.0.1July 2026Preferred hosts moved to openmarket.xyz; legacy hosts remain supported; authentication uses X-OpenMarket-KeyAuthentication header renamed
v1.0.0May 2026Documented REST /v1/points surface, WS overview (book / nonbook, regions), auth, errors, rate limits, full data-type referenceNone — initial documented baseline

v1.0.1 — July 2026

The preferred public API hostnames now use openmarket.xyz, and REST authentication uses X-OpenMarket-Key. Request paths and response formats are unchanged.

Changed

  • REST requests now use https://api.openmarket.xyz instead of https://api.kiyotaka.ai.
  • Regional WebSocket endpoints now use *.ws.api.openmarket.xyz instead of *.ws.api.kiyotaka.ai.
  • REST authentication uses the X-OpenMarket-Key header.

Compatibility

The existing api.kiyotaka.ai REST host and regional *.ws.api.kiyotaka.ai WebSocket hosts remain supported. No shutdown date has been confirmed; a separate notice will be published before support ends.

v1.0.0 — May 2026

This release establishes v1.0.0 of the Data API documentation: a single coherent description of the public HTTP and WebSocket interfaces that customers integrate against today. The URL path /v1 on REST matches this baseline; future incompatible HTTP contract changes would be reflected in documentation and versioning together.

Documented REST API

  • Unified query endpoint — All historical and aggregated series use GET /v1/points with a required type parameter and shared time-range parameters (from, period, interval). See Introduction and Quickstart.
  • Authentication — X-OpenMarket-Key on every REST request. See Authentication.
  • Stable response envelope — Responses use a series array; each item has id metadata and points with a Point payload. Timestamps use { "s", "ns" } (seconds UTC, optional nanoseconds). See Introduction.
  • Data-type catalogue — Documented types include candles (side-agnostic and per-side trade aggregates), open interest, funding rate, liquidations, volume profile, TPO / market profile, orderbook heatmap, liquidation heatmap, TP/SL heatmap, bitcoin dominance, implied volatility, skew, Polymarket analytics, and metadata / discovery. Per-type parameters (for example blockSize, maxDepth, tenor, coin vs rawSymbol) live on each REST page under REST API in the sidebar.
  • Cross-exchange and transforms — Examples cover multi-exchange queries and transforms such as grouping and USD normalization where your tier allows. See Quickstart and Rate limits for tier gates (for example Advanced for multi-exchange aggregation).

Documented WebSocket API

  • Two endpoint families — book (orderbook depth) vs nonbook (trades, liquidations, funding, open interest, volume profile). See WebSocket overview.
  • Regional endpoints — Singapore and Europe hostnames; append ?encoding=json. See Connecting.
  • Channels — Documented channel types include TRADE, TRADE_AGG, BLOCK_BOOK_SNAPSHOT, LIQUIDATION, FUNDING_RATE, OPEN_INTEREST, and VOLUME_PROFILE_AGG, with subscribe parameters where applicable.
  • Session flow — Authenticate with your API key, subscribe via JSON-RPC, optional compression (for example brotli) as shown in the overview examples. See Subscribing and Connection lifecycle.

Operations and governance

  • Weight-based rate limits — Per-minute and burst budgets by plan tier; formulas for base weight, exchange multiplier, and depth surcharge where applicable. Metadata / discovery requests are zero weight. See Rate limits.
  • Structured errors — JSON error objects with codes such as INVALID_API_KEY, INVALID_PARAMS, RATE_LIMITED, tier or range denials, and HTTP status mapping. See Errors.

Reference