An odds data feed is a continuous supply of betting prices, and the market details around them, from bookmakers and exchanges to the software that uses them: an odds screen, a model, an alert or a bot. A feed of bookmaker prices is built by reading what each bookmaker publishes, again and again, so every price in it is a reading taken at a known moment, not a direct line into the bookmaker.
That is why fresh does not mean instant. A feed can deliver a price a second after reading it, yet the bookmaker may have changed that price a moment after the previous read, and the read time stamped on it is the only honest measure of its age. Anything built on a feed, from an odds screen to a bot, can be no fresher than the feed beneath it; the betting tools in Australia overview shows where each kind of tool fits.
How a feed is built from bookmaker prices
A feed runs a collector for each source. The collector reads the bookmaker's published markets, compares each reading with the last, and passes on what changed, with the time of the reading. A mapping step ties each bookmaker's event, market and selection names to the feed's own ids, and the result goes out to subscribers.
Reading takes time, which is why prices arrive on a cycle. With illustrative figures, a collector that can read 4 markets a second from one bookmaker, and watches 120 markets, takes 120 / 4 = 30 seconds to get round them all, so each market is re-read every 30 seconds. Add 60 more markets at the same rate and the cycle grows to 180 / 4 = 45 seconds. Wider coverage at the same read rate means older prices.
A feed can spend its reads where they matter, reading markets near their start more often than tomorrow's. With the same 240 reads a minute and an illustrative schedule:
| Markets | How many | Read every | Reads a minute |
|---|---|---|---|
| Starting within 10 minutes | 12 | 10 seconds | 12 x 6 = 72 |
| Starting within 2 hours | 60 | 60 seconds | 60 |
| Later | 300 | 5 minutes | 300 / 5 = 60 |
| Total | 372 | 192 of the 240 available |
Read in one flat cycle, the same 372 markets would each wait 372 / 4 = 93 seconds between reads; the schedule gives the markets about to start a 10-second read and still leaves reads spare.
An exchange that offers its own streaming service is different: its changes come straight from its own systems, with no read cycle in between. A pricing supplier's feed to the bookmakers that use its prices is different too: it is sent from where its prices are set, and is a separate product from a feed that collects the prices bookmakers publish.
Push and pull delivery
Once the feed has a price, it reaches you one of two ways. With pull, your software asks on a timer, called polling, and gets the current prices each time. With push, the feed keeps a connection open and sends each change as it finds it, usually a full snapshot when you connect and then changes only.
With illustrative figures for 50 markets that each change twice a minute:
| Pull, every 10 seconds | Push | |
|---|---|---|
| Messages a minute | 50 x 6 = 300 requests | About 50 x 2 = 100 changes |
| Messages carrying a new price | At most 100 of 300, about 33% | All of them |
| Extra wait once the feed has a change | Up to 10 seconds | Delivery time only |
| What goes wrong | Wasted requests and rate limits | A dropped connection or a missed change |
Push has a failure pull does not: if one change goes missing, your copy of the market stays wrong until the next change or snapshot. Sequence numbers show a gap the moment a message is missed, and heartbeats, small messages sent while nothing changes, make silence mean a dead connection rather than a quiet market. Ask for both.
Neither method makes a reading fresher. If the feed reads a bookmaker every 30 seconds, a pushed change can be up to 30 seconds old when it is sent. Which delivery suits you, and what each costs in requests, is covered in how to choose an odds API.
Why every price needs a timestamp
A price without a time can only be guessed at. Three moments matter, and a good feed gives you the first two:
| Time | What it tells you | Without it |
|---|---|---|
| Read time, when the feed read the price | The price's age: now - read time | A price read 3 seconds ago and one read 3 minutes ago look the same |
| Sent time, when the feed sent it | How much of the delay is the feed's own | Collection delay and network delay cannot be told apart |
| Received time, when your software got it | Your own share of the delay | A slow server of yours goes unnoticed |
A feed that reads a bookmaker rarely knows when the bookmaker changed a price, so the read time is the best evidence there is, and a feed that stamps only its send time hides its own delay.
Use one clock for all of it. Write times in UTC with the offset shown, such as 2026-10-07T03:32:05Z, and keep your server's clock synchronised, because a price's age is a subtraction between two clocks. With illustrative figures, a price read 26 seconds ago looks 18 seconds old on a server whose clock runs 8 seconds slow, and it passes a 20-second freshness rule it should fail. Betting latency sets out every stage of delay, from the read to the bookmaker accepting a bet.
Normalising names across bookmakers
Prices from different bookmakers can only be compared once the feed ties each bookmaker's wording to one event, market and selection, and every bookmaker names teams, players, markets and lines its own way. Mapping is where a feed most easily goes quietly wrong.
Lines show the trap. In an illustrative AFL player market, three bookmakers word one line three ways and a fourth offers a different line:
| Bookmaker's wording | What wins | Same bet as 30 or more disposals? |
|---|---|---|
| 30+ Disposals | 30 or more | Yes |
| Disposals Over 29.5 | 30 or more | Yes |
| To Have 30 Or More Disposals | 30 or more | Yes |
| Disposals Over 30.5 | 31 or more | No |
Disposals are whole numbers, so over 29.5 and 30 or more are one bet, while over 30.5 needs 31. A feed that files the fourth line with the other three shows its price, say $2.10 against $1.80 elsewhere, as 2.10 / 1.80 - 1 = 16.7% better for the same bet. It is really a price for a harder one.
Names need the same care: J. Citizen, Jack Citizen and CITIZEN, Jack can be one player, while two players in one team can share a surname. A sound feed keeps each bookmaker's wording beside the id it mapped to, so you can audit any match, and leaves a line it cannot place unmapped rather than filing it with the nearest one. Racing's version of the problem, track names and race numbers, is covered in what a racing odds API should carry.
Gaps and outages
Feeds fail in ordinary ways: a bookmaker changes its site and its collector stops reading, the feed goes down, or your connection drops. The danger is that a failure often shows up as silence, not an error, and the last price stays on screen looking as current as the rest.
With illustrative prices, Bookmaker C's collector last read successfully 4 minutes ago, at $2.40, and every bookmaker, C included, has since moved to $2.10:
| What the screen shows | What happens when you bet $50 | |
|---|---|---|
| Frozen price kept | $2.40 at Bookmaker C, the best price | You expect 50 x 2.40 = $120 back if it wins; the live price is $2.10, so at best 50 x 2.10 = $105, or the bet is refused |
| Stale price marked unknown | No price from C | Nothing misleading to chase |
A feed should mark a source's prices unknown once its last good read is older than a cut-off, such as 60 seconds, and say which source is down. On your side, alarm on the age of each source's last good read, not on errors. A suspended market is different: that is a status to pass on, not a gap.
Gaps matter after the event too. A missing hour in stored prices is drawn as a straight line from the last price before it to the first after, a path the price never took, so a feed's history should mark gaps as gaps. Historical odds data covers testing on prices with holes in them.
What real-time and live mean for odds data
A real-time odds feed, strictly, sends each change as it happens at the source. For bookmaker prices collected by reading, the honest description is "as at the last read", which can be seconds or minutes old. To test a real-time label, ask the provider how it gets each bookmaker's prices and how often: an answer given as a read interval describes a collected feed, whatever the label says.
Live odds data usually means current prices that keep updating. Under the Interactive Gambling Act (s 8A(3) and s 10B), online betting on any sporting event, here or overseas, may be offered to people in Australia only before it starts. Only a provider licensed in an Australian state or territory may offer it (s 15AA), and even a licensed provider may not accept an online bet on a sporting event once it has started.
Note: Publishing a feed's prices is different from using them. Liquor & Gaming NSW says it is an offence to publish gambling advertising relating to a sporting event in progress in NSW, including live odds (checked October 2026). Get legal advice before showing odds publicly; B337 does not give legal advice.
If you check a few prices before betting by hand, you need no feed: an odds screen shows the same prices, with their times, and no code.
B337's Terminal and API Odds
B337's Terminal is built on reads too: it collects prices in repeated reads, not tick by tick, and shows each as at the time displayed, so the bookmaker's own price may have moved since. Check it in your account before you bet.
For software rather than a screen, API Odds supplies live odds from Australian bookmakers and from Betfair, for racing and sports, over the B337 API; it places no bets and comes with Terminal View. Access and coverage are agreed with the team at setup, coding is required, and the full price, with any charges on top of the plan, is confirmed before you pay. Bets placed through B337, from code or from the Terminal, use credits. Betfair is a trade mark of its owner; B337 is not affiliated with it.
Risk: Betting involves risk. Every price in a feed is a reading from the past, the bookmaker can refuse or re-price a bet, many bookmakers restrict automated betting in their terms, and there is no guarantee of profit from any data. See responsible gambling for limits and support.
For free and confidential support call 1800 858 858 or visit gamblinghelponline.org.au.