Odds API vs odds feed: what's the difference?
OddsRelay · · Updated · 4 min read
Odds API and odds feed usually name the same product from two angles. The choice that changes your build is whether the data arrives raw or already matched.
Is an odds API different from an odds feed?
- 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 someone maintains and refreshes the data over time. The odds feed glossary entry has the precise sense.
A vendor leaning on "API" is usually advertising a clean integration. A vendor leaning on "feed" is usually advertising upkeep. Neither word tells you whether the data is ready to use.
Raw versus matched is the real fork
A raw feed gives you prices as each bookmaker shows them: per event, per bookmaker, per market, each market stamped with when it last changed. That is the right input for comparison tables, content and your own models. For an oddsmatcher it is half the job. The opportunity lives in the relationship between a back price and a lay price, so with raw data you pair every bookmaker price against an exchange yourself, decide how much lay money is enough, and only then render anything.
{
"id": "or_evt_917dd44bce05",
"sport_key": "soccer_epl",
"sport_title": "Premier League",
"commence_time": "2026-09-20T14:00:00Z",
"home_team": "Arsenal",
"away_team": "Chelsea",
"bookmakers": [{
"key": "william_hill",
"title": "William Hill",
"region": "uk",
"last_update": "2026-09-17T02:18:09Z",
"markets": [{
"key": "h2h",
"last_update": "2026-09-17T02:17:02Z",
"outcomes": [{ "name": "Arsenal", "price": 2.9 }, { "name": "Chelsea", "price": 2.5 }]
}]
}]
}A matched feed does the pairing before you receive the data. Each outcome carries its back offers (a bookmaker's price) and its lay offers (an exchange's price plus available, the money on offer at that price). OddsRelay supplies both forms. The feed covers 140+ bookmakers, 60+ of them live in the UK & Ireland, bet365 included, and the matched boards pair those prices against Betfair, Smarkets, Matchbook and BETDAQ. The six matched boards and raw are on every plan.
{
"meta": {
"feed_type": "standard", "region": "uk",
"odds_format": "decimal",
"processed_at": "2026-09-17T02:20:57.271Z",
"last_seen": {
"betfair_exchange": { "soccer": "2026-09-17T02:20:56Z" },
"william_hill": { "soccer": "2026-09-17T02:20:55Z" }
},
"count": 26,
"version": "v2",
"next_cursor": null
},
"data": [{
"event_id": "or_evt_917dd44bce05",
"sport_key": "soccer_epl",
"sport_title": "Premier League",
"commence_time": "2026-09-20T14:00:00Z",
"home_team": "Arsenal",
"away_team": "Chelsea",
"markets": [{
"key": "h2h",
"outcomes": [{
"name": "Arsenal",
"back": [{ "bookmaker": "william_hill", "price": 2.9, "link": null }],
"lay": [{ "exchange": "betfair_exchange", "price": 3.0, "available": 175, "link": null }]
}]
}]
}]
}The feed carries prices and nothing derived from them. Each pair is liquidity-gated. The rating and qualifying loss are simple arithmetic on the pair, done at your own commission rate. The oddsmatcher widget shows them, and in your own code the rating is one line: const rating = (back / lay) * 100. 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. Either your code asks for the data, or the vendor sends it to you.
| Model | How it works | What it means for your build |
|---|---|---|
| Pull (polling) | Your code calls the endpoint when it wants the current board | Simple to build and easy to reason about. You own the loop and the caching |
| Push | The vendor sends changes to you over a socket or a webhook | Changes arrive without a request. You run a listener, handle reconnects and replay gaps |
OddsRelay is pull only. There is no webhook, socket or stream. Every data reply carries an ETag. Send it back as If-None-Match, and an unchanged board comes back as an empty 304 that costs no tokens. The polling guide covers the loop, and webhooks vs polling weighs the two designs.
Pull versus push is a separate axis from raw versus matched. You can poll a raw feed or a matched one. Settle which data you need first, then how it arrives.
What should you ask, whichever word a vendor uses?
- Which bookmakers, and is bet365 in the list? A feed that skips the book your users care about most is a partial feed. Ask for the bookmaker list and check which of them are live today.
- Paired output, or raw prices? Does each outcome carry an exchange
layoffer with the money available, or do you build the matcher? This is the question that sizes your own work. - Can you check freshness in the response? A feed that answers but serves old prices is not delivering. Ask what each response tells you about the age of its data.
On the third question, look for fields in the response. Every board carries meta.processed_at (also sent as the X-Processed-At header), the time the board was built. A matched board adds meta.last_seen per venue and sport, so now minus that value is an upper bound on a price's age. Raw stamps each market with its own last_update. Every product on sale meets a maximum update time of 10–20 s. The freshness guide explains how to read each field.
For the wider build-versus-buy picture, see how to get bookmaker odds data. The buyer's guide turns these questions into a checklist.
Check a board against your own build
The coverage page shows each bookmaker and sport as live or interrupted right now. The quickstart makes one call against the standard board. When the shape fits, request access.