How to test an odds feed before you buy

Test an odds feed the way you'll actually use it. Pull a real response with a trial key, check the specific books and markets you need, verify the prices are fresh against the source, and confirm the matched fields are present and correct. A live dashboard and a working trial tell you more than any sales deck. This is the hands-on checklist, in the order you should run it.

The mistake is evaluating a feed on the vendor's terms: a coverage table in a PDF, a headline book count, a promise about latency. Those are claims. A trial key turns every claim into something you can check in an afternoon, against your own requirements. If a vendor won't give you one, that answer is itself a result.

Can you get a trial key without a sales call?

You should be able to, and a serious odds-data supplier lets you get a key and make a real call without booking a demo first. This is the first test, and a surprising number of vendors fail it. Being routed straight into a sales pipeline before you can see any data is a red flag: it usually means the coverage won't survive contact with your requirements.

OddsRelay issues a free trial key that returns the full UK feed, bet365 included, matched against exchange lay prices. You call the same production endpoint your paying integration would, so what you test is what you'd ship. Keys are or_test_* for the trial and or_live_* in production, and both go in an Authorization: Bearer header, never a query string.

What should your first call look like?

Call the odds endpoint once, with your trial key, and read the response by hand before you write a single line of integration code. One authenticated GET against /v1/odds/{type} returns predictable JSON. Here is the request, with a placeholder key:

curl -s https://api.oddsrelay.io/v1/odds/matched \
  -H "Authorization: Bearer or_test_YOUR_KEY" \
  -H "Accept: application/json"

# What to check in the response, in order:
#   1. Are YOUR books present?  (look for "bet365" in back.bookmaker)
#   2. Are YOUR markets present? (match_odds, over_under, btts ...)
#   3. Is each row fresh?        (the freshness / last_seen field)
#   4. Are the matched fields there and sane? (lay, rating, qualifying_loss)

A single matched row carries the pieces you're evaluating. The shape below is illustrative, not live data:

{
  "event": "Newcastle vs Aston Villa",
  "market": "match_odds",
  "selection": "Newcastle",
  "back": { "bookmaker": "bet365", "odds": 2.05 },
  "lay":  { "exchange": "betfair", "odds": 2.08, "liquidity": 1620 },
  "rating": 98.4,
  "qualifying_loss": -0.14
  // ... region, feed_type and freshness fields elided
}

Read the fields against how you'll use them. The back block should name a book you care about; the lay block should pair it with a real exchange price and non-zero liquidity; rating and qualifying_loss should be present and plausible. If those matched fields are missing, you're looking at a raw-price feed dressed up as a matched one. For the full field-by-field breakdown, see the response envelope and the API docs.

Does it cover your books and your markets?

Check coverage against your list, not the vendor's. A feed that carries 60 books is useless to you if it skips the three you need. Pull the response and confirm your specific bookmakers appear in back.bookmaker, then confirm the markets you trade appear in market. bet365 is the one to test hardest: it is the book most often promised and least often maintained well.

OddsRelay covers 60+ UK books with bet365 included as standard, and lay prices from three exchanges (Betfair, Smarkets, Matchbook). If you sell into emerging markets, check for the domestic South African and Nigerian books the big aggregators tend to skip. The coverage dashboard lists what is live right now, so you can confirm your list before you even mint a key. There is a fuller method for this in evaluating coverage.

How do you verify the data is fresh?

Compare a few live rows against the source and read the freshness field. Take a few rows from the response and check the odds against what the bookmaker and exchange are showing in a browser at the same moment: they won't match to the tick, but they should be close and moving. Then check the row's freshness field: it should show the price was seen seconds ago, not minutes. A stale price is worse than a missing one, because it looks usable and isn't.

Be precise about the freshness claim you're testing. OddsRelay's honest posture is pre-match polling on roughly a few-second cycle, which suits pre-match matched betting and arbitrage. Treat any vendor promising "real-time" in-play streaming without qualification with caution, and ask to see freshness published on a dashboard rather than asserted in a call.

Does caching behave the way it should?

Test the ETag and 304 behaviour, because it decides your bandwidth and polling cost. Make the first call, note the ETag header on the response, then repeat the call with an If-None-Match header carrying that value. A well-built feed answers with 304 Not Modified and no body when nothing has changed, so you only pay for bytes when the board actually moves.

# First call returns an ETag header, e.g. ETag: "board-8f3a1c"
curl -s https://api.oddsrelay.io/v1/odds/matched \
  -H "Authorization: Bearer or_test_YOUR_KEY" \
  -H 'If-None-Match: "board-8f3a1c"' -i | head -n 1
# -> HTTP/1.1 304 Not Modified   (no body; you re-use the cached board)

If a feed always returns a full body regardless of If-None-Match, your polling costs scale with your call rate instead of with real change. That is a design smell worth catching during the trial.

Should you load-test it?

Lightly, and with your real query, not a synthetic one. Run the exact call your product will make, at roughly the rate it will make it, for a few minutes. You are checking two things: that latency stays steady under your actual pattern, and that rate limits and error responses are sane and documented. You are not trying to break the service; you are confirming it behaves under the shape of load you'll create.

Pay attention to the failure modes. A 429 should carry a clear retry signal, and errors should be structured JSON you can handle, not an HTML page. How a feed behaves when something goes wrong tells you more about the team behind it than the happy path does.

What does good look like, and what are the red flags?

Good looks like a trial you can start yourself, a live dashboard showing current coverage and freshness, and a specific answer to "do you cover book X, market Y, in region Z." You can verify every one of those in an afternoon.

Run the checklist

Testing a feed is not complicated: get a key, make the call, and check your own books, markets, freshness, caching and matched fields against how you'll actually use them. If you want the wider decision framework around this, choosing an odds API covers the full build-versus-buy and vendor picture.

When you're ready to test rather than read, start a free trial: you get the full UK feed, bet365 included, matched against exchange lay prices, so you can run every check above against real data. It powers a leading UK matched-betting platform today, and you can see the coverage live on the coverage dashboard before you commit.