The raw data layer
The raw odds API that carries the lay side, not just back prices
Most raw odds APIs stop at bookmaker back prices and leave the hardest input — the exchange lay side — for you to source elsewhere. OddsRelay's raw endpoints (GET /v2/odds/raw, or one fixture at GET /v2/odds/event/{eventId}) deliver 60+ UK bookmakers in one consistent schema, each book's own prices per event, with the exchange lay price and its liquidity carried alongside. It's the raw half of an odds data API for teams that want to own the matching — with the lay side already in the payload. Raw is enablement-gated, so ask us to switch it on for your key.Powers a leading UK matched-betting platform.
$ curl api.oddsrelay.io/v2/odds/standard?region=uk \
-H "Authorization: Bearer or_live_••••••••••••"GET 200 · application/json
{
"event_id": "or_evt_9f2c1a7b",
"fixture": "Arsenal v Chelsea",
"sport": "Football",
"region": "uk",
"market": { "key": "match_odds", "name": "Match Odds" },
"selection": "Arsenal",
"back": { "bookmaker": "bet365", "odds": 2.10 },
"lay": { "exchange": "Smarkets", "odds": 2.12 },
"rating": 99.1,
"qualifying_loss": 0.42,
"potential_profit": 18.90,
"last_update": "2026-07-08T12:34:48Z"
}One schema, per-book selections — not cross-book normalised
The raw feed gives you one consistent envelope across 60+ UK bookmakers: the same response shape, the same market keys, the same structure, so you integrate one schema instead of sixty. What it deliberately does not do is reconcile the same selection across books — each book's outcomes arrive as that book labels them, its own team and runner strings, because resolving one row per selection across sixty books is exactly the matching problem the matched-betting layer, arbitrage and +EV surfaces solve for you. If you want the reconciled, one-row-per-selection view, those are the endpoints; if you want clean per-book inputs to build your own logic on, this is it. The API docs show the response shape field by field.
The differentiator over a plain aggregator is the exchange side. Where an exchange exists for the market, the raw event carries the exchange lay price and the liquidity behind it alongside the bookmaker back prices — the half most raw feeds leave you to integrate separately. The exchange-lay page covers how that side is priced, and the coverage dashboard lists every book and exchange live.
Discovery: sports and events before you pull odds
Two discovery endpoints sit under the raw feed so you can see what data exists before you request it. GET /v2/sports enumerates the sports and competitions in season; GET /v2/events lists the fixtures for a sport, each with a has_coverage flag telling you which downstream surfaces — standard, arbitrage, +EV — that event supports. Together they let a build enumerate the board, then pull raw odds for exactly the fixtures it cares about, one at a time via GET /v2/odds/event/{eventId} or in bulk via GET /v2/odds/raw.
It's the shape a comparison engine, a bespoke rating model or an in-house matching pipeline wants: clean, structured inputs and full freedom over what you build from them. When you'd rather the relational work arrived done, the matched feed is the same coverage at a higher altitude.
Delivery, auth and enablement
Raw is a server-to-server surface: one HTTPS endpoint, authenticated with a Bearer token or an x-api-key header, JSON out, on a pre-match ~3s polling cycle, monitored, with published freshness. Bookmaker deep-links are off by default and enabled per key. It shares the envelope conventions of the rest of the v2 surface — a format=bare option, decimal or American odds, ISO-8601 or unix timestamps, strong ETags with 304s and gzip — so it plugs into the same client you'd write for any OddsRelay endpoint.
Raw is enablement-gated rather than a self-serve default: the raw scope is switched on for your key on request, and until it is the endpoints answer honestly — a non-raw key sees raw_not_in_scope, a key awaiting provisioning sees raw_not_enabled. bet365 is available on the raw feed as an add-on, not bundled; on the matched feed bet365 is included as standard. Raw coverage is UK today, with regions shown honestly on the regions view.
What you get
One consistent schema
60+ UK bookmakers in one envelope — consistent market keys and structure, so you integrate one shape, not sixty. Selections stay per-book by design.
The exchange lay side included
Where an exchange exists, each event carries the exchange lay price and its liquidity alongside the back prices — the half most raw aggregators omit.
Sports and events discovery
`GET /v2/sports` and `GET /v2/events` (with a `has_coverage` flag) let you enumerate the board before pulling raw odds for the fixtures you want.
Server-to-server, on request
`Bearer`/`x-api-key` auth, deep-links off by default, and the raw scope switched on per key — the mint path is enablement-gated, not self-serve.
An honest note
Raw is per-book prices with the lay side, not opportunities: one consistent schema, but each book keeps its own selection strings — reconciling them into one row per selection is the matched / arbitrage / +EV feed. It's enablement-gated (the raw scope is switched on per key on request, so we describe it as available on request, not live), server-to-server, pre-match (~3s polling) not in-play. bet365 is an add-on on raw, included as standard only on the matched feed. Raw coverage is UK today; the exchange lay side is carried only where an exchange exists.
Questions
What does the raw odds API return?
Per-bookmaker prices in one consistent schema: each book's own back prices per event across 60+ UK bookmakers, with the exchange lay price and its liquidity carried alongside where an exchange exists. It does not reconcile selections across books, pair back to lay, or rate opportunities — that is the matched, arbitrage and +EV feeds.
Is the raw feed cross-book normalised?
The schema is: one consistent envelope, market keys and structure across every book. The selections are not — each book's outcomes arrive as that book labels them. Reconciling the same selection across sixty books into one row is the matching layer the matched, arbitrage and +EV endpoints do for you.
How is the raw scope switched on?
Raw is enablement-gated: the raw scope is provisioned on your key on request rather than sold self-serve. Until it is enabled the endpoints respond honestly — raw_not_in_scope for a key without raw, raw_not_enabled for a key awaiting provisioning. Ask us and we switch it on.
How do I discover what data exists?
Two discovery endpoints: GET /v2/sports enumerates the sports and competitions in season, and GET /v2/events lists the fixtures for a sport with a has_coverage flag showing which downstream surfaces each event supports. Then pull raw odds per event via GET /v2/odds/event/{eventId} or in bulk via GET /v2/odds/raw.
Is bet365 in the raw odds API?
bet365 is available on the raw feed as an add-on. On the matched feed, bet365 is included as standard across every feed type.
In this cluster
The odds API pillar
The full product: coverage, feed types, processing and delivery.
Raw feed product
The catalogue view: what raw is for and how it's licensed.
Exchange lay coverage
How the lay side carried alongside the raw back prices is priced.
Matched-betting data
The reconciled, one-row-per-selection view raw leaves to you.
vs The Odds API
Where a raw aggregator is the right buy.
vs OddsPapi
Breadth-first raw aggregation vs a UK-deep raw feed with the lay side.
Per-book prices, the lay side included
See the covered books live on the dashboard, then ask us to switch raw on for your key — server-to-server, one schema, your logic on top.