A Unified API for Prediction Markets

Say a trading firm wants to market-make on sports and politics on a prediction market.

The first step they’d complete would be connecting to Kalshi’s API in order to build and run their models on prediction markets.

This is fairly straightforward. Kalshi has an API. The desk can pull markets, stream order books, place orders, and track fills.

Then it wants Polymarket. Now there are two authentication schemes, two identifier systems, two order formats, two sets of balances, and two WebSocket clients. There is also a growing file called something like venue_normalization.py, which nobody wants to touch while a game is live.

This is the problem a unified prediction market API is meant to solve. The challenge is not in the integration itself, but rather in making several different venues behave like one system—and keeping it that way.

The exponential cost of marginal venues

Kalshi and Polymarket each have their own respective docs, however, they’re each subject to nonstop changes. This makes any implementation feel like an uphill battle.

An adapter per venue is a workable first step.

Then account for inventory logic, batch orders, partial fills, cancels, reconnects, fee logic, and whatever changes in the next API release (which for Polymarket Int’l is about once a week).

Polymarket, Kalshi, or whichever venues you choose to trade also have their own identifiers and contract structure. It quickly becomes serious infrastructure, overwhelming in complexity, with open orders hanging on for dear life.

This affects any firm trading with size. If any part of the adapter is using an old book or misses a fill, the strategy’s view of inventory is no longer reliable.

Prediction markets have a liquidity problem

Saving engineering time is useful. An even better reason to unify several prediction markets is liquidity.

Assume the same outcome trades on two venues. A desk wants to buy 100,000 contracts at 52 cents or better. Kalshi has 80,000 contracts available inside that limit. Polymarket has 35,000.

There are 115,000 contracts available across the two books. This is obvious. The less obvious part is that many trading systems still treat the books as unrelated because the identifiers, market data, and order APIs are unrelated.

A price-comparison screen can show both books. It still leaves the strategy to work out which contracts are equivalent, how much size is available in total, and how to split the order. A unified trading API can easily expose an aggregate book and perfectly route the order across eligible venues.

River Markets’ API handles this with two levels of identity. Every exchange listing receives its own numeric River ID. River keeps an aggregated order book for generic assets, and its smart order routing can send a generic-asset order across member venues or restrict it to selected exchanges.

River Markets makes additional liquidity available to clients through separate supported venues via one market and order model.

Market matching between venues is not as simple as a string search

Sports make the identity problem easy to see. “Boston to win” could mean the next game, the series, the conference, or the championship. Two venues can list similarly worded markets with different start times or resolution rules.

A River ID identifies one listing on one exchange. It does not pretend that every similar market is the same instrument. Generic assets are the cross-venue layer used to group equivalent listings.

Any firm using River Markets can keep its strategy logic on consistent, stable River IDs, instead of using quickly-outdated exchange-native API identifiers.

What River’s API covers

Currently we support Kalshi, Polymarket, and Polymarket US as available venues. Our unified REST API covers it all: market search, order books, prices, orders, fills, positions, balances, and subaccounts. See the list of supported exchanges.

Simple orders include market and limit orders with IOC, FOK, GTC, and GTD instructions. The complex-order API includes take-profit and stop-loss orders, icebergs, pegs, and smart takers. View River order types.

Those last three have obvious uses:

The less exciting endpoints are probably more important in production. River Markets supports batch order entry, order editing and cancellation, cancel-all, queue position, fair values, and normalized fee schedules. A desk can monitor books and trades over WebSockets, then receive orders and fill updates through the same API. The Python SDK signs requests locally and automatically reconnects and restores active subscriptions. See River WebSockets and fee schedules.

This is not only an API or multi-venue problem

A sports market maker focused on Kalshi still has to manage batches of quotes, posted orders, queue position, fees, fills, and inventory across a large slate. Advanced and algorithmic order types such as pegs, icebergs, and smart takers are incredibly useful long before a second venue is added.

The multi-venue case makes the benefit easier to measure because it adds aggregate liquidity. The same system can search another supported venue, group equivalent listings, and route orders without giving the strategy an entirely new order model.

Election desks run into the same issue when several markets move on one piece of news. Other brokerages and trading applications might want a singular order model for a client-facing instance which retrieves the best prices, and gets the best fills. Execution happens with ~20ms latency across different exchanges and River Markets handles it seamlessly.

Frequently asked questions