Betting Exchange API 2026: Back and Lay Data in One Feed

A sportsbook sets a price, takes the other side of your bet, and builds its margin into the number. An exchange never takes a position. It matches one customer against another and charges commission on net winnings, usually somewhere between 2% and 5% depending on the venue and your account. Nothing is baked into the odds, which is why exchange prices sit so close to the true market probability.

What you get back from the API reflects that structure:

• Two sides, not one. Every selection has back prices and lay prices. The back price is what you can win at; the lay price is what you can take a bet at.
• Depth at each price level. A good exchange feed returns a ladder: several price levels per side, each with the amount available. A sportsbook feed has nothing equivalent.
• Liquidity as a first-class signal. A price with GBP 40 behind it and the same price with GBP 40,000 behind it are not the same information.
• Traded volume. Some exchanges publish how much has already matched on a selection, which tells you where the money actually went.
• A spread to interpret. The gap between best back and best lay is the exchange's version of vig. Narrow spread means a confident, liquid market.

The practical consequence: the midpoint of a tight back and lay spread on a liquid market is a better fair-value estimate than almost anything a sportsbook will show you. That is why exchange prices get used as the benchmark in the same way Pinnacle lines do, and why some Australian tools use Betfair as their sharp reference instead of Pinnacle.

Every major exchange publishes its own API, and every one of them gates access differently. This matters more than it looks, because the official API is the only route that lets you place a bet. Aggregator feeds are read-only.

One pattern to notice: the UK and European exchanges all charge in some form, either an activation fee or a request fee, while the US event contract venues give market data away to their own users. Their terms then limit what you can show to anyone else, so read the data clause before you build a product on a member key.

Polymarket API: Official Endpoints or an Aggregated Feed

Polymarket is two venues under one name, and each has its own API. Polymarket International (polymarket.com) runs a crypto-based order book that settles on the Polygon blockchain, and it blocks new positions from the United States. Polymarket US (polymarket.us) is regulated by the CFTC as a designated contract market, trades in US dollars and serves US residents after an identity check. The two have separate docs, separate terms and separate order books, so a price on one is not a price on the other.

Both official APIs serve market data free with no key. The International docs cover the Gamma API for events and markets, the CLOB API for prices and order books, a Data API and public WebSockets, with per-IP read limits in the thousands of requests per 10 seconds. The Polymarket US docs cover a public Retail API for markets, sports leagues and order books at 25 requests per second. Trading and the US WebSockets need a signed key. Both quote a price between 0 and 1 per contract, an implied probability that you convert before you compare it with a sportsbook line.

Use the official API to trade, or to feed a model that only you use. For anything other people will see, read the terms first. The International terms bar trading firms, fintech companies and data distributors from using the data without a written agreement, and the Polymarket US rulebook bars redistributing exchange information without permission. A sports app that wants Polymarket next to sportsbook odds is better off with a feed that already maps it to the same games and whose terms cover display. The Coverage Map lists the odds APIs that carry Polymarket US, and a second filter does the same for Polymarket International.

Pulling four exchange APIs is the easy part. Making their data comparable is the job, and it is the reason people end up buying a feed instead of building one.

These providers have already done the matching work, and publish exchange prices under the same event and market ids as their sportsbook data. Coverage splits along a clear line: a UK and European cluster around Betfair, Smarkets, Matchbook and Betdaq, and a US cluster around Kalshi, Polymarket, Novig and ProphetX. Very few feeds carry both.

Disclosure: Some links on this page are affiliate links. They cost you nothing extra and help keep this directory free.

One caveat worth reading twice. Odds-API.net is the only provider in the directory that documents back and lay ladder depth. Assume everyone else flattens an exchange into a single best price and hands it to you as though it were another bookmaker quote. That is fine for line shopping and useless for sizing. Ask for a sample payload before you commit.

Odds APIs That Carry Betfair Exchange

Five questions settle it, roughly in this order.

1. Do you need to place bets, or only read prices?

If you need to place, cancel or update bets, you need an account and the exchange's own API. No aggregator in our directory executes trades. Many teams end up with both: an aggregator for the cross-venue picture, and one official API for execution on the venue they actually trade.

2. Which cluster of exchanges?

UK and European work means Betfair, Smarkets, Matchbook and Betdaq. US work means Kalshi, Polymarket, Novig and ProphetX. Pick the cluster first, because almost nothing covers both well.

3. Depth or top of book?

If your model sizes stakes or estimates slippage, you need ladder depth and there is one provider serving it. If you only need a reference price, a flattened best-price feed is cheaper and simpler.

4. Pre-match or in-play?

The deepest exchange coverage in the directory is pre-match only. If you need in-play exchange prices, your realistic options are the exchange's own streaming API or one of the live odds APIs that carries Betfair in its book list.

5. How are commission and staleness handled?

Assume prices are gross of commission unless the docs say otherwise, and check that every price carries a timestamp. Both assumptions have burned people building arb tools.