Skip to main content
​
New
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.
​
New
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 and Trades channel.
​
Action required
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 and Kalshi.
​
Changed
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:
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.
​
New
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 and Kalshi.
​
New
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 to get started.