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

# Changelog

> New features and improvements across the ParlayX API.

<Update
  label="September 2, 2026"
  tags={["New"]}
  rss={{
title: "ProphetX listings in the discovery contract",
description:
  "The Listing union gains a ProphetX variant, addressed by strikeId with no side. No market returns one yet.",
}}
>
  The `Listing` union returned by the discovery endpoints gains a ProphetX variant.

  * A ProphetX listing is `{ "venue": "PROPHETX", "strikeId": "...", "executable": true }`.
  * There is no `side`. A ProphetX strike identifies both the market and the outcome.
  * The `POLYMARKET` and `KALSHI` variants are unchanged.

  No market returns a ProphetX listing yet. Code that switches exhaustively over
  `listing.venue` needs a branch for the new variant.

  The listing shape and the fields it carries are in
  [List Event Markets](/api-reference/discovery/list-event-markets).
</Update>

<Update
  label="August 19, 2026"
  tags={["New"]}
  rss={{
title: "Kalshi on the market data stream",
description:
  "Kalshi markets are subscribable on the /v1/orderbook stream. Address a market by its ticker; the book and the trade tape are YES-priced.",
}}
>
  Kalshi markets are subscribable on the `/v1/orderbook` stream, on both the
  `book` and `trade` channels.

  * Address a market by its ticker:
    `{ "venue": "kalshi", "ticker": "KXNBA-25-LAL" }`.
  * The book and trade tape are YES-priced. There is no separately subscribable
    NO book; you derive it from the YES book.
  * The optional `side` accepts `"yes"` only. A subscribe naming `"no"` returns
    `UNKNOWN_MARKET`.

  Addressing, the NO derivation with a worked example, and the trade tape fields
  are in
  [Subscriptions & markets](/streaming/subscriptions#deriving-the-no-side-of-a-kalshi-market)
  and [Trades channel](/streaming/trades).
</Update>

<Update
  label="August 14, 2026"
  tags={["Action required"]}
  rss={{
title: "Balance available excludes cash on resting orders",
description:
  "GET /v1/polymarket/balance and GET /v1/kalshi/balance now report available net of cash committed to your resting buy orders. Check any order sizing that reads it.",
}}
>
  `GET /v1/polymarket/balance` and `GET /v1/kalshi/balance` report `available` net
  of the cash committed to your resting buy orders.

  Neither venue holds that cash aside while an order rests: the balance each one
  reports still contains every dollar pledged to an open buy order. `available` is
  now the amount you can commit beyond the orders you already have resting.

  On `GET /v1/polymarket/balance`, `total` keeps its previous value. It includes
  collateral committed to resting orders, so it does not move when you place or
  cancel one. Because of that, `available`, `unconverted` and `claimable` no longer
  add up to `total`: the difference is the committed collateral, which the endpoint
  does not publish as its own field.

  `GET /v1/kalshi/balance` reports `available` alone, as before. It publishes no
  `total`, so there is no component sum to reconcile there.

  What to check: any order sizing that reads `available` on either endpoint (it now
  leaves your resting orders funded, so a size derived from it will be smaller),
  and any reconciliation that adds the Polymarket components and compares the
  result to `total`.

  Field semantics and units are in the API reference for
  [Polymarket](/api-reference/polymarket/get-balance) and
  [Kalshi](/api-reference/kalshi/get-balance).
</Update>

<Update
  label="August 10, 2026"
  tags={["Changed"]}
  rss={{
title: "Kalshi order tickers are validated on submit",
description:
  "POST /v1/kalshi/orders now rejects a malformed ticker with 400 before creating an order, and an unknown market returns 404 instead of 500.",
}}
>
  `POST /v1/kalshi/orders` now checks the shape of `ticker` before creating an
  order, and reports what the venue said when it refuses one.

  ### Ticker validation

  `ticker` must be uppercase alphanumeric segments joined by `-`, with `.`
  allowed inside a segment for a decimal strike:

  ```
  ^[A-Z0-9]+([.-][A-Z0-9]+)*$
  ```

  For example `KXPRES-2028` and `KXBTCD-26AUG0607-T64599.99`. There is no limit
  on the number of segments, and no restriction on the series prefix, so tickers
  for newly listed series are accepted without any change here.

  A ticker that does not match is rejected with `400 INVALID_REQUEST` and **no
  order is created**. The message states the expected shape.

  **This is a behaviour change.** Lowercase tickers such as
  `kxmlbgame-26aug05torhou-hou` were previously accepted, and are now rejected
  rather than being upcased for you. Kalshi tickers are case-sensitive, so
  correcting the case on your behalf could submit an order against a different
  instrument than the one you named. Send tickers exactly as Kalshi publishes
  them.

  ### Clearer errors when the venue refuses an order

  A refusal from Kalshi now reaches you as a `4xx` describing what happened,
  instead of a generic `500`:

  * An unknown or expired market returns `404 NOT_FOUND`.
  * An order larger than your available balance returns
    `400 INSUFFICIENT_BALANCE`.
  * Any other refusal returns `400 INVALID_REQUEST`.

  The venue's own explanation is included in the `message` field. A genuine
  Kalshi outage or a network failure still returns a `5xx`, so a `4xx` from this
  endpoint always means the request itself needs changing — retrying it
  unchanged will not succeed.
</Update>

<Update
  label="August 5, 2026"
  tags={["New"]}
  rss={{
title: "Positions",
description:
  "GET /v1/polymarket/positions and GET /v1/kalshi/positions return your open positions with value and unrealized P&L.",
}}
>
  Your open positions are now readable per venue. Each row carries your
  weighted-average entry price, an indicative mark, current value, and
  unrealized P\&L.

  ### Polymarket

  * `GET /v1/polymarket/positions` returns one row per outcome token, ordered by
    `tokenId`. Pass `tokenId=` to filter.

  ### Kalshi

  * `GET /v1/kalshi/positions` returns one row per market ticker and side,
    ordered by `ticker` then `side`. Pass `ticker=` to filter.

  See the API reference for
  [Polymarket](/api-reference/polymarket/list-positions) and
  [Kalshi](/api-reference/kalshi/list-positions).
</Update>

<Update
  label="August 3, 2026"
  tags={["New"]}
  rss={{
title: "Public API baseline",
description:
  "The REST trading and discovery endpoints and the real-time market data stream published at launch.",
}}
>
  The baseline of everything documented on this site today: REST trading and
  discovery endpoints, and the real-time market data stream.

  ### Authentication

  Signed-request authentication for every endpoint, plus two utility routes:

  * `GET /v1/whoami` verifies your key and returns the calling identity.
  * `GET /v1/time` returns the server time for request signing.

  ### Discovery

  Browse the cross-venue market catalog:

  * `GET /v1/sports`
  * `GET /v1/sports/competitions`
  * `GET /v1/sports/events`
  * `GET /v1/sports/events/{eventId}/markets`
  * `GET /v1/markets`

  ### Polymarket trading

  Venue-explicit order management and balance:

  * `POST /v1/polymarket/orders` submits a market (FOK/FAK) or limit (GTC) order.
  * `GET /v1/polymarket/orders` lists orders with filtering and pagination.
  * `GET /v1/polymarket/orders/{orderId}` returns a single order.
  * `DELETE /v1/polymarket/orders/{orderId}` cancels a working order.
  * `GET /v1/polymarket/orders/{orderId}/fills` returns an order's fills.
  * `GET /v1/polymarket/balance` returns the pod's venue balance.

  ### Kalshi trading

  The same order lifecycle, in Kalshi's own vocabulary (ticker, side, action,
  count, priceCents):

  * `POST /v1/kalshi/orders`
  * `GET /v1/kalshi/orders`
  * `GET /v1/kalshi/orders/{orderId}`
  * `DELETE /v1/kalshi/orders/{orderId}`
  * `GET /v1/kalshi/orders/{orderId}/fills`
  * `GET /v1/kalshi/balance`

  ### WebSocket market data

  The `/v1/orderbook` stream delivers order book snapshots, incremental deltas,
  and trades, with subscription management over a single authenticated
  connection. See the [streaming overview](/streaming/overview) to get started.
</Update>