A betting odds API sells you prices from bookmakers and an exchange for your own code to read. Whether it is usable turns on six answers a pricing page rarely gives: coverage by bookmaker and by market rather than a headline count, how often each price is re-read, how the same selection is identified across bookmakers, what history it keeps, what happens when a limit is hit or a bookmaker stops answering, and what the licence lets you do with the data.
Two providers can each list 35 bookmakers and differ in every way that matters to your software, so each question below carries a number to measure on a trial key rather than a claim to take on trust. An API earns its cost once your method is written as code: of the betting tools in Australia, a few bets a week by hand wants an odds board instead.
A coverage number is not coverage
Ask for coverage as a list, one row per market and one column per bookmaker, then score it against the accounts you hold. A count of bookmakers is an average over markets you do not bet, at books you cannot bet into.
With illustrative prices on one head to head priced by 8 of the provider's bookmakers, where you hold accounts at 3 of them and the fair price works out at $2.20:
| What you are looking at | Top price | Edge against a fair $2.20 |
|---|---|---|
| All 8 bookmakers the API carries | $2.30 | 2.30 / 2.20 - 1 = 4.55% |
| The 3 bookmakers you hold | $2.18 | 2.18 / 2.20 - 1 = minus 0.91% |
The screen shows a 4.55% edge and your accounts offer minus 0.91%. Nothing in the data is wrong: the top price belongs to a bookmaker you cannot bet with. Filter to your own accounts before anything is ranked, and drop any operator not licensed to take your bet, which how to check a bookmaker is licensed covers against the ACMA register.
Coverage also differs market by market inside one bookmaker, which a count hides. The measurable version: on one event, how many priced selections come back for each bookmaker? A book returning 2 where another returns 60 is covered in name only.
Update cadence: a repeating cycle or an event
Bookmaker prices are collected by reading what the bookmaker publishes, over and over, so every price is a reading taken at a moment. Ask for the read interval per bookmaker, whether it tightens as an event nears, and whether the provider reads on a timer or is told by its source that something changed.
The cycle sets a floor on how stale your prices are, and also how many of the bookmaker's own moves you ever see. With an illustrative 45-second cycle and a market the bookmaker repriced 12 times in the final 3 minutes:
- The window is 3 x 60 = 180 seconds, so the feed reads it 180 / 45 = 4 times.
- At most 4 of those 12 prices are ever recorded, and the other 8 are never seen.
- A price you act on is on average 45 / 2 = 22.5 seconds old, and up to 45 seconds old.
An event-driven feed sends a change when it learns of one, which removes your polling wait but not the read cycle underneath it: if the provider still reads that bookmaker every 45 seconds, a pushed change can be 45 seconds old on arrival. A read time on every price therefore matters more than the label on the plan. Odds data feeds explained covers delivery, and betting latency the stages after it.
Tip: The cycle is only half of it. Over one busy hour, count the different prices a trial key returns for one bookmaker, then count that bookmaker's own moves over the same hour. The difference is the moves the feed never saw, and no read time stamped on a price will tell you about them. Measuring the cycle itself is covered in choosing an odds API.
Identifying the same selection at two bookmakers
This is the hard problem, and the one nobody advertises. Two bookmakers name the same player, team, market and line their own way, and prices can only be compared once every version maps to one selection. A feed that gets it wrong does not return an error. It returns two rows.
The audit takes one request. Pick a market priced by 8 bookmakers with two outcomes each: 8 x 2 = 16 priced selections, which should land on exactly 2 identified selections. Count what comes back. An illustrative result:
| Identified selection | Prices on it | What it really is |
|---|---|---|
| 1 | 7 | The over side, 7 of 8 bookmakers |
| 2 | 5 | The under side, 5 of 8 bookmakers |
| 3 | 2 | The under side again, under two other spellings |
| 4 | 1 | The over side again, with a spelling of its own |
| 5 | 1 | The under side again, one more spelling |
All 16 prices are present, spread over 5 selections instead of 2, so three rows are splits. The damage is arithmetic. Say the 7-price row gives a fair price of $2.20 and the stray over price is $2.25. Against that fair, $2.25 is an edge of 2.25 / 2.20 - 1 = 2.27%. On its own row it is the only price there, so a fair built from that row sits exactly where that bookmaker sits and the edge computes as 0.00%. The real edge is hidden and a false zero shown in its place.
That count is also the acceptance test, and it needs no answer from a salesperson. On a two-way market priced by N bookmakers, prices divided by identified selections should come to N: here it is 16 / 5 = 3.2 against the 8 it should be, and the shortfall is the split rate. Run it over a hundred events and you can rank two providers on one number. The questions behind that number, whether a feed matches on structured fields or on the event title as text and what it does with a market it cannot place, are set out in odds data feeds explained and choosing an odds API.
History, and whether the close is really the close
Ask what is stored rather than whether history exists: every read or only the changes, opening prices, the last price before the start, how far back, whether it comes in bulk, and whether a gap is marked as a gap. An unmarked gap is the one to insist on, because a chart and a backtest both read it as a price that simply did not move.
Closing prices need their own question, because a feed's close is its last read and not the bookmaker's last price. With the same 45-second cycle, you took $2.45, the bookmaker's true last price was $2.30, and the feed's last read before the start was $2.40:
| Closing price used | Closing line value |
|---|---|
| The bookmaker's true last price, $2.30 | 2.45 / 2.30 - 1 = 6.52% |
| The feed's last read, $2.40 | 2.45 / 2.40 - 1 = 2.08% |
One bet measures 6.52% or 2.08% depending on which close you hold, a gap of 4.44 points that runs through every bet in the sample. Closing line value covers why the number is worth getting right, and historical odds data which stored prices are fit to test on.
Rate limits, and a bookmaker dropping out
Ask what a rate limit counts, because a request, an event and a selection are three different quotas, and whether it is per key or per account. With an illustrative cap of 60 requests a minute, 12 events watched and one request returning one event:
- Polling every 5 seconds is 12 / 5 = 2.4 requests a second, so 144 a minute, or 144 / 60 = 2.4 times the cap.
- The quickest poll inside the cap is 60 / 12 = 5 polls a minute, one every 12 seconds.
- If one request returns a whole sport, a poll costs 1 request, 60 polls a minute fit, and the cap stops mattering.
What a single request returns changes every figure above, which is why a quota alone says little.
A bookmaker also drops out of a feed from time to time, which is where the coverage you bought stops matching the coverage you have. What a feed owes you when that happens is covered in odds data feeds explained; what matters for a buying decision is that it moves the number from the first section.
Example: In the market above the top price is $2.30 and the second is $2.22. Lose the $2.30 bookmaker for an hour and your edge against a fair $2.20 falls from 4.55% to 2.22 / 2.20 - 1 = 0.91% for that hour, so the 8-bookmaker market you are paying for is a 7-bookmaker market while it lasts.
So score a provider on how often each bookmaker was actually present over a day, not on how many it lists. That measurement is the honest version of the coverage count, and a trial key long enough to take it is worth asking for.
An odds API and an execution API are different products
An odds API returns prices and places no bets. An execution API takes a bet your code sends and puts it into a bookmaker account you hold. Some vendors sell both, but they are two integrations with two failure modes, and this is the distinction most buyers miss.
The tolerances differ. A 30-second-old price is fine for a model studying yesterday's markets and useless for a bet going on in the next minute. A feed that misses a change costs you a signal, while an execution call that times out can cost you two bets, because a timeout means no answer arrived rather than that the bet failed. What to check before a bet placement API touches real money covers that side, from idempotency to reconciliation against the bookmaker's records.
One question joins them. An odds API hands you its own ids for an event, market and selection, and a betting API needs ids the bookmaker accepts. Those id spaces are rarely the same, so ask whether the feed's selection id can be sent to the betting call, or whether you must search by name on the way in. Searching by name puts you back in the mapping problem with a stake attached.
The licence: the one question a trial key cannot answer
Every question above is measurable. You poll, you count, you diff, and the data answers. What you may do with the data is in no response body: it is in the licence, and the only form that answer comes back in is writing. So it is the question to settle first, and it is the one most often left until after the integration is built, by which point the answer can no longer change anything cheaply.
Ask it against the thing you are actually building rather than in general, because a licence prices a private model and a public screen differently. Racing carries rights on top of the provider's licence, set out in what a racing odds API should carry, and what you may keep after you cancel is in historical odds data. A provider that will not put the answer in writing has answered it. None of this is legal advice.
Odds and betting APIs from B337
API Odds delivers live racing and sports odds from Australian bookmakers and Betfair over the B337 API, for your own models, tools and strategies. It places no bets. It comes with Terminal View, coding is required, and coverage, access and price are agreed with the team before you pay, so bring the questions above to that conversation. Prices are read on a repeating cycle rather than tick by tick, so a price can trail the bookmaker's own. Betfair is a trade mark of its owner, and B337 is not affiliated with any bookmaker or exchange.
Bets from your own code are the separate product. The Execution API is REST over HTTPS with your key in an X-API-Key header. The place-bet call is asynchronous, answering with a correlation id, and the result follows by polling the bet-status endpoint or by a signed callback carrying a Bet-Signature header, an HMAC-SHA256 of the body keyed with your API key. Its target_odds is a floor and not a fixed price: below it the bet is refused, and at or above it the bet goes on at the bookmaker's current price. Every bet goes to a session running on your own computer, in an account you hold, so nothing is placed while that computer is off. It is set up with the team, coding is required, and bets placed through B337 use credits, a per-bet usage charge on top of the plan price.
Risk: Betting involves risk. Bookmakers can restrict or close accounts and void bets, automation can fail, prices move, and a positive expected value bet can still lose. There is no guarantee of profit. Bookmaker terms govern what is allowed, and no software prevents an account being restricted or closed. See responsible gambling for limits and support.
For free and confidential support call 1800 858 858 or visit gamblinghelponline.org.au.