What Is a Sportsbook API? A Developer's Guide

A sportsbook API is a programmatic interface that returns a bookmaker's betting data (events, markets, selections and odds, plus live scores and results) as structured JSON instead of a web page. Developers use one to build odds comparison sites, trading models, betting apps and data products without collecting prices from every bookmaker by hand.

This guide explains what the data looks like, how it is delivered, why normalization is the hard part, and what people build with it. The examples use the PulseScore API, but the concepts apply to any odds feed.

What does a sportsbook API return?

A bookmaker's website is a set of boards: one per sport, league and match. A sportsbook API exposes the same boards as data, and almost every odds feed is built from the same handful of objects:

• Events: a fixture with a sport, a league, a home and an away side, a start time and the bookmaker's own event id.
• Markets: one question you can bet on, such as the match result, total goals over or under a line, a handicap, both teams to score or a player prop.
• Selections: the possible answers inside a market, each with a price. Most feeds quote decimal odds, so 2.10 means a stake of 1 returns 2.10 including the stake.
• Live state: for in-play events, the score, the match clock and per-period scores, plus a flag that shows when a market is suspended.
• Racing cards: races instead of matches, with runners, jockeys, trainers, each-way terms and fractional and decimal prices.
• Results: final scores and period breakdowns once the event is over and, on some books, the settlement of each selection.
• Deep links: the event's path on the bookmaker's own site, so an app can send a user straight to the market.

Pre-match vs live (in-play) odds

Pre-match boards list upcoming fixtures, often weeks ahead, and their prices move slowly as money and news come in. Live boards cover matches in progress: prices can move every few seconds, markets are suspended after a goal or a break of serve and reopen moments later, and new markets appear as the game develops. Most APIs serve the two separately because they need different refresh strategies.

Odds formats and implied probability

Decimal odds (2.10), fractional odds (11/10) and American odds (+110) are three ways to write the same price. Decimal is the easiest to compute with: the implied probability is 1 / odds, so 2.10 implies about 47.6%. Add up the implied probabilities of every outcome in a market and you get more than 100%; the excess is the bookmaker's margin. The guide to implied probability and overround covers conversions and no-vig prices.

What does a normalized event look like?

Here is a live Premier League event from Betfair Sportsbook, as GET /api/betfair-sb/live-events?sport=soccer returns it, trimmed to one market:

{
  "eventId": "35974468",
  "sport": "soccer",
  "league": "English Premier League",
  "home": "Ipswich",
  "away": "Liverpool",
  "startTime": "2026-09-04T19:00:00.000Z",
  "score": { "home": "0", "away": "1" },
  "matchClock": { "minute": 27, "second": 14, "period": "INPLAY_FIRST_HALF" },
  "slug": "/betting/football/english-premier-league/ipswich-v-liverpool/e-35974468",
  "markets": [
    {
      "canonicalMarket": "MATCH_RESULT",
      "rawName": "Match Odds",
      "period": "FULL_TIME",
      "marketId": "924.534695661",
      "isActive": true,
      "selections": [
        { "canonicalOutcome": "HOME", "rawName": "Ipswich", "odds": 15, "isActive": true, "selectionId": "48324" },
        { "canonicalOutcome": "DRAW", "rawName": "The Draw", "odds": 5.5, "isActive": true, "selectionId": "58805" },
        { "canonicalOutcome": "AWAY", "rawName": "Liverpool", "odds": 1.2, "isActive": true, "selectionId": "56323" }
      ]
    }
  ]
}

Every field has a job:

• eventId, marketId and selectionId are the bookmaker's own ids, so the same match has a different id on every book.
• canonicalMarket, period and canonicalOutcome are the normalized layer: MATCH_RESULT, FULL_TIME and HOME mean the same thing on every bookmaker.
• rawName keeps the bookmaker's own label ("Match Odds", "The Draw"), so nothing is lost in translation.
• odds is a decimal number, and line (on totals and handicaps) carries the number the market is about, such as 2.5 goals.
• isActive is false while a market or selection is suspended.
• score, matchClock and slug appear when the bookmaker publishes them. Some books publish odds only, so treat them as optional.

Why does normalization matter?

Bookmakers describe the same bet in different words. Betfair Sportsbook calls the match result market "Match Odds" and its middle outcome "The Draw"; Bet365 calls them "Full Time Result" and "Draw". Total goals at 2.5 shows up as "Goals Over/Under", "Match Goals" or "Over/Under 2.5 Goals" depending on the book and on whether the match is live, and a book in another country labels everything in its own language.

Without a normalization layer you write and maintain one parser per bookmaker. With one, all of those labels arrive as canonicalMarket: "OVER_UNDER" with line: 2.5 and the outcomes OVER and UNDER, and one function reads every book:

def match_result(event):
    """Full-time 1X2 prices from any bookmaker's event, e.g. {"HOME": 15, "DRAW": 5.5, "AWAY": 1.2}."""
    for market in event["markets"]:
        if market.get("canonicalMarket") == "MATCH_RESULT" and market.get("period") == "FULL_TIME":
            return {
                sel.get("canonicalOutcome") or sel["rawName"]: sel["odds"]
                for sel in market["selections"]
                if sel.get("isActive")
            }
    return None

The safe pattern is to switch on the canonical fields and fall back to rawName when a normalized value is missing or looks wrong, which is what the or sel["rawName"] does above.

Normalization has a second half that no schema solves completely: recognizing the same match on different books. Event ids are per bookmaker and team names vary ("Man City" on one book, "Manchester City" on another), so cross-book tools match on sport, start time and cleaned-up team names. The odds comparison tutorial shows one way to do it.

How is odds data delivered?

There are three common delivery models, and many products use more than one.

REST polling

You request a board (GET /{sport}/events, GET /live-events) and get a paginated JSON snapshot back. REST is simple to cache, easy to debug with curl and works on every plan, but to notice one moved price you fetch the whole board again. Compression matters here: a gzip-encoded board is 6 to 14 times smaller on the wire.

WebSocket push

You open a socket for one bookmaker and one sport, and the server pushes a frame with every live event about once a second. There is no polling loop and no request counting, but each frame repeats the whole live board.

Delta streams

A delta stream sends each board once, then once a second only the events, markets and selections that changed. One socket can carry many bookmakers and sports, bandwidth drops to a few kilobytes per second per board, and a client that reconnects with its last sequence number resumes without a new snapshot. The trade-off is that your client applies the changes to its own copy of the board.

Speed has limits on every model. At PulseScore, stream deltas are batched once a second, so a change typically reaches you 1 to 2 seconds after the bookmaker makes it; it is not a sub-second feed. The comparison of REST, WebSocket and delta streams goes deeper, with code for all three.

Official bookmaker APIs vs aggregated odds APIs

Most sportsbooks do not publish a self-serve public API for their odds; the prices live on their websites and apps. Betting exchanges and prediction markets often do run their own APIs, but those are built for trading on that one venue, with their own accounts, authentication and schema.

An aggregated sportsbook API collects many bookmakers, normalizes them and serves them through one key and one schema. You trade dozens of integrations for one, and in exchange you depend on the provider's coverage, freshness and uptime, so those are the things to test before you commit; the checklist for choosing a sports odds API lists them. An odds data API is also read-only: it tells you prices, scores and results, and it does not place bets.

What can you build with a sportsbook API?

• Odds comparison: pull the same match from many books and show the best price for every outcome.
• Value and arbitrage detection: flag prices that stray from the market consensus, or combinations of prices on different books that guarantee a return.
• Trading desks and models: feed live prices into pricing models, track line movement and back-test strategies against results.
• Media and affiliate widgets: match centers and tipster pages with live odds and a deep link straight into the book.
• Prediction markets vs sportsbooks: compare Polymarket and Kalshi prices, which come from traders, with bookmaker odds on the same match.
• Racing products: race cards with runner prices and each-way terms for horse racing and greyhounds.

How PulseScore implements a sportsbook API

PulseScore is a sportsbook API that serves 60+ bookmakers across 35+ sports through one API key and one schema, from Bet365, PS3838 and Betfair to DraftKings, FanDuel, BetMGM, Polymarket and Kalshi. The sportsbook API overview lists every book.

• Same paths on every bookmaker: /{sport}/leagues, /{sport}/events, /live-events and race cards on racing books. Only the /api/{bookmaker} prefix changes; Bet365 uses /api/v3/bet365.
• Three delivery modes: REST on every bookmaker, a live WebSocket feed on 50+ of them, and the Stream API (in beta) for delta streams.
• Normalized markets: canonicalMarket, period and canonicalOutcome, with the bookmaker's rawName kept alongside.
• Results and deep links: a results archive on supported bookmakers, and the bookmaker's own slug wherever the book exposes one.
• A free plan: BASIC includes every bookmaker, 500 requests a month and 1 req/sec per bookmaker. Live WebSocket and Stream API access start with PRO.

Your first call needs one header:

curl --compressed "https://api.pulsescore.net/api/v3/bet365/live-events?sport=soccer" \
  -H "X-Secret: YOUR_API_KEY"

The getting started guide walks through keys, pagination and your first live board, and the API documentation covers every endpoint, error code and rate limit.