Betfair API Australia: Sports Betting API, Odds API & Horse Racing API Guide

Automation

AUTHOR

Betfair

View more from this author

What is the Betfair API?

The Betfair API is a betting API that allows developers, traders and data analysts to access betting markets, sports odds, horse racing data and account functionality programmatically.

Through the Betfair API Australia platform, customers can retrieve betting odds, monitor market activity, analyse sports/racing betting data and place bets automatically.

The Betfair API includes access to both sports betting markets and horse racing markets through the same API platform and endpoints. While terms like “Sports Odds API” and “Horse Racing API” are commonly used, they both refer to different use cases of the broader Betfair API.

Betfair provides one of the most comprehensive exchange betting APIs available.

Sports Odds API

The Betfair Sports Odds API gives developers access to live and historical betting odds across thousands of sporting events.

Using the same Betfair API platform, developers can retrieve odds and market data through endpoints such as Market Catalogue and Market Book to build:

Odds comparison tools
Trading applications
Predictive models
Automated betting strategies

The Sports Odds API covers a wide range of sports including football, tennis, cricket, basketball and more.

Horse Racing API

The Betfair Horse Racing API provides access to thoroughbred, harness and greyhound racing markets. Developers can retrieve:

Race fields
Runner information
Starting prices (BSP)
Market odds
Traded volume
Race metadata

This makes it one of the most widely used horse racing APIs in Australia for betting analysis and automation.

How to access the Betfair API?

All Betfair Australia accounts can generate API keys for Betfair automation.

Step 1 — Login to Betfair

Login here: Betfair Login

If the website does not appear logged in afterwards, login again.

Step 2 — Open the Betfair API Visualiser

Go to: Betfair API Visualiser

The Session Token (ssoid) field should populate automatically.

Step 3 — Check for Existing Betfair API Keys

Click getDeveloperAppKeys
Click Execute

If API keys already exist:

Click the + icon to expand the results
Any key marked Active = Yes can be used immediately

If no keys exist, continue to Step 4.

Step 4 — Create New Betfair API Keys

Click createDeveloperAppKeys
Enter a globally unique application name
Click Execute

The Version 1.0-DELAY Betfair API key will be available immediately for testing and development.

The Version 1.0 (Live) key will also be created, however, it will be inactive, and once testing has been completed with the Version 1.0-DELAY key, activation of the live key may be applied for by completed the below form.

Live Key Application Form: Betfair Australia and New Zealand Personal API Application Form – Fill out form

Now I’ve got my API keys, how do I get started?

To interact with Betfair’s API, you’ll need a few things to get started:

Coding Tool (e.g. Visual Studio Code)
Coding language package (e.g. Python)
A Betfair account in good standing
An API key

Once you’ve got all of these, then you can start to explore what the API has to offer.

Whilst the documentation is detailed, it can be a bit overwhelming as a starting point for someone looking to get started without a coding background.

The first thing to understand is that Betfair has two different types of API and each has their own advantages and disadvantages:

Polling (or REST) API
Streaming API

To start with, we recommend just starting with the Polling API which is kind of like having a text exchange with a friend: You send a request for information with your authentication, and the API will send a response back to you with that information.

How do I get authenticated?

To authenticate yourself in the Betfair API, you’ll need to send a login request using your code. A request will require:

Account Username (or email address)
Account password (special characters html encoded)
Account API Key
Certificates for non-interactive login (optional)

When you send a login request, you will receive a response from Betfair which will carry a status of “SUCCESS” or “FAILURE”. A successful login will return a session token (ssoid) that should be retained for further use.

This token will remain valid for 12 hours and additional requests to the API should contain your session token and app key – sending account credentials is not required once you have a valid session token.

What does a typical request look like?

There are two main endpoints that can be polled to gather information about markets:

listMarketCatalogue
listMarketBook

To poll the market catalogue, you will need to use a market filter to determine which markets you would like returned. Some of the common filter parameters are:

textQuery – This can search for track names or team names
eventTypeIds – This is the code/s for sport or racing codes e.g. ‘61420’ is AFL
eventIds – A list of events from listEvents
competitionIds – A list of competition ids from listCompetitions
venues – A list of horse or greyhound tracks
bspOnly – True/False for markets that offer BSP
turnInPlayEnabled – True/False for markets that go inplay
marketCountries – List of 2-letter country codes (e.g. ‘AU’, ‘GB’)
marketTypeCodes – List of market types (e.g. ‘WIN’, ‘PLACE)
marketStartTime – Time Range
raceTypes – A list of race types for horse racing (e.g. ‘Harness’)

And you’ll generally need to add another list of ‘Market Projections’ which is the kind of data about the market that you want to be returned

COMPETITION – contains competition name
EVENT – contains time zone and venue information
EVENT_TYPE – contains sport/racing code name
MARKET_START_TIME
MARKET_DESCRIPTION – contains BSP, Commission, Persistence, Race Type and clarifications information (including Greyhound Reserve Runner Boxes)
RUNNER_DESCRIPTION – contains Selection Name
RUNNER_METADATA – contains Metadata like Barrier/Trainer/Jockey for Horse Racing Only

There is a limit of 1000 markets that will be returned if both of MARKET_DESCRIPTION and RUNNER_METADATA are not requested, 200 if one of them is requested and 100 if both are requested. If you are encountering ‘TOO_MUCH_DATA’ errors, try tightening your market filter.

To poll the market book, you will need to send a list of market ids collected from listMarketCatalogue and a price projection.

A price projection will contain a list of priceData values and a parameter that determines if the cross matcher is returned

SP_AVAILABLE – BSP pool information prior to reconciliation
SP_TRADED – BSP pool information after reconciliation
EX_BEST_OFFERS – Returns the top price levels (default is 3 levels, max of 10)
EX_ALL_OFFERS – Returns all unmatched prices
EX_TRADED – Returns all matched prices

The request limit for listMarketBook is 200 points and points are assigned per market id based on the values in the priceData list:

Null – 2 points
SP_AVAILABLE – 3 points
SP_TRADED – 7 points
EX_BEST_OFFERS – 5 points
EX_ALL_OFFERS – 17 points
EX_TRADED – 17 points
EX_BEST_OFFERS + EX_TRADED – 20 points
EX_ALL_OFFERS + EX_TRADED – 32 points

Due to this limit, it is recommended that listMarketBook requests are sent in batches of no more than 10 market ids (6 if requesting EX_ALL_OFFERS + EX_TRADED).

What is the difference between a market book and a market catalogue?

A market book contains all of the pricing information about the market and therefore changes very frequently and so if you’re monitoring the market, you can be polling this quite frequently whereas a market catalogue does not change very often and so should be polled less often.

A market catalogue may be updated in a very small number of circumstances:

The market is re-timed due to a delay
The selections in the market are reordered

What does a typical response look like?

A response to a listMarketBook or listMarketCatalogue call will return a data “object” in the form of a Market Book Object or Market Catalogue object which are essentially boxes in which different data points are packaged in a predictable and cohesive way depending on the depth and granularity of data in the initial request.

To gather a specific piece of data contained within one of these boxes, you’ll generally need to follow a path down through the object like you would locating a document in a set of folders.

e.g. The venue from a Market Catalogue Object is found in marketCatalogue.event.venue

Depending on the level of data requested, within a Market Catalogue Object the following small data objects may be returned:

Competition
Event
EventType
MarketDescription
List of Runner Catalogue objects with a small Metadata object

Whereas a Market Book Object would just contain a list of Runner Book objects with the pricing information for each runner

Often, merging data from both objects is required to gather a cohesive picture of the market and this can be accomplished by joining on common market id and selection id values (and also handicap if the market is a handicap market)

How do I place a bet?

Bets are, you guessed it, objects and so you’ll need to be able to build a Bet object to place a bet. It is possible to place multiple bets into a single market in one request, but you cannot bet across multiple markets in one request.

A placeOrders request will contain the market id of interest and then a list of placeInstructions objects.

A place instruction objects must contain:

orderType (‘MARKET_ON_CLOSE’, ’LIMIT_ON_CLOSE’, ’LIMIT’)
selectionId
handicap (0 for most markets)
side (‘BACK’, ‘LAY’)
one of the below objects corresponding to the value under orderType
- LimitOrder
  - Price (valid tick)
  - Size (2 decimal places)
  - PersistenceType (‘LAPSE’, ‘PERSIST’, ‘MARKET_ON_CLOSE’)
- LimitOnCloseOrder
  - Price (valid tick)
  - Liability (2 decimal places)
- MarketOnCloseOrder
  - Liability (2 decimal places)

How do I know if my bet placed?

A response to a placeOrders request will comprise a status, list of placeInstructionReports for each order and, if applicable, an error code. A successful bet will return a status of ‘SUCCESS’ and a failed bet will return ‘FAILURE’. It is important any failed bets are logged and investigated as learning opportunities as failed bets can impact the way a strategy is implemented, and, at sufficient scale, may cause some upstream network congestion.

Where to now?

Once you’ve familiarised yourself with the basics of using the Betfair API, you can start building your own strategy. The general recommendation is to utilise the Python language with pre-built wrappers like Flumine rather than building a system from scratch.

To find out more: