Odds API vs odds feed: what's the difference?

An odds API and an odds feed are mostly the same thing, described from two angles. "API" stresses the interface: the request you make and the response you get back. "Feed" stresses the supply: a continuously maintained stream of prices that someone keeps current. Both deliver bookmaker odds as structured data your software can read. The word a vendor picks tells you what they want to emphasise, not which product you are buying.

So if you arrived here trying to choose between the two, the honest answer is that the naming is not the decision. The distinction that actually changes your build is raw versus matched, and below that, pull versus push. This post covers all three, then the three questions worth asking whichever word a vendor uses.

Is an odds API different from an odds feed?

Not really. They name the same underlying thing from two viewpoints. To see why, it helps to hold each word still for a moment.

• API is the interface word. It names the contract: an endpoint you call, the parameters you pass, and the JSON shape you get back. See what an odds API is for the full definition.
• Feed is the supply word. It names the property that the data is maintained and refreshed continuously, not fetched once. See the odds feed definition for the precise sense.

In practice the same product is both. You call an API; behind it sits a feed someone keeps fresh. A vendor leaning on "API" is usually advertising a clean integration. A vendor leaning on "feed" is usually advertising reliability and upkeep. Neither word, on its own, tells you whether the data is ready to use.

What's the difference that actually matters?

The real fork is raw versus matched. This is the distinction the two words tend to hide, and it is the one that decides how much you still have to build after you integrate.

A raw feed gives you back prices only: the odds each bookmaker is showing for a selection, as JSON, on some cadence. That is genuinely useful, but for matched betting or arbitrage it is half the job. The opportunity lives in the relationship between two prices, not in either price alone, so you still have to pair every back price against an exchange lay price yourself, build a liquidity model, and compute the position before any of it renders.

A matched feed does that pairing before you receive the data. Each row carries the bookmaker back price, the current exchange lay price for the same selection, and the derived rating and qualifying_loss fields. OddsRelay delivers the matched form: 60+ UK books with bet365 included, each price paired against three exchanges (Betfair, Smarkets and Matchbook). Here is the shape of a single matched row (illustrative, not live data):

{
  "event": "Arsenal vs Chelsea",
  "market": "match_odds",
  "selection": "Arsenal",
  "back": { "bookmaker": "bet365", "odds": 2.10 },
  "lay":  { "exchange": "betfair", "odds": 2.14, "liquidity": 1840 },
  "rating": 98.1,
  "qualifying_loss": -0.12
  // ... region, feed_type and freshness fields elided
}

The lay block paired to the back price, with rating and qualifying_loss computed, is the part a raw API cannot give you. With a raw feed you build that step; with a matched feed your oddsmatcher renders on day one. For a field-by-field walk through the envelope, see the anatomy of a response.

Pull or push: how does the data reach you?

Beneath the naming sits a delivery question: do you pull the data, or does it get pushed to you? Both models are common, and each shapes your build differently.

OddsRelay is a pull model: you call one authenticated endpoint and read predictable JSON, with ETag/304 support so an unchanged board costs you almost nothing. Our honest latency posture is pre-match polling on roughly a few-second cycle, which suits pre-match matched betting and pre-match arbitrage well. We do not claim real-time or in-play streaming, because that is not what we ship.

Note that pull versus push is a separate axis from raw versus matched. You can pull a raw feed or pull a matched one; the delivery model and the data's readiness are independent choices. Sort out which data you need first, then how it arrives.

What should you ask regardless of the word?

Whether a vendor calls it an API or a feed, three questions cut through the naming and tell you what you are actually getting:

1. Coverage, with bet365 included? A feed that skips the book everyone wants is a partial feed. Ask for the bookmaker list, and check that bet365 is in it as standard rather than as a special case you babysit.
2. Matched output, or raw prices? Does each row carry the paired exchange lay price with rating and qualifying_loss, or do you build the matcher? This is the months-of-work question.
3. Reliability you can check? A feed that is up but stale is not delivering. Ask whether freshness, uptime and latency are published rather than asserted.

These hold across the whole market, and they are the questions we built OddsRelay to answer in the affirmative. For the wider build-versus-buy picture, including the domestic books the big aggregators tend to skip, see how to get bookmaker odds data.

The short answer

Odds API and odds feed name the same data: "API" foregrounds the interface, "feed" foregrounds the upkeep. The decision that matters is raw versus matched, with pull versus push as a separate delivery choice. OddsRelay delivers the matched form: 60+ UK books with bet365 included, each price paired against Betfair, Smarkets and Matchbook, over a single pull endpoint. It powers a leading UK matched-betting platform today. You can see what's live right now on the coverage dashboard, or pick it up first-hand with a free trial.