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

Most odds APIs are built around sportsbooks. You ask for a game, you get one price per selection per book. A betting exchange API works differently, because an exchange has no house price to quote. It has an order book, with people trying to back on one side and people trying to lay on the other, and the interesting part is not just the price but how much money sits behind it.

That difference shapes everything downstream. If you are building an arbitrage scanner, a matched betting tool, a fair-odds model, or anything that needs to know what a market really thinks, exchange data is the closest thing to a clean signal you can buy. This page covers the four UK and European exchanges that publish APIs, the US cluster of exchange-style venues, and the aggregators in our API directory that already carry exchange prices.

• What a betting exchange API gives you
• Official exchange APIs and what they cost
• Why cross-exchange work is hard
• APIs that serve exchange data in one schema
• What you can build with it
• How to choose
• Frequently asked questions

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. That is a regulatory and business model difference, not a quality difference.

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.

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.