Which Sports and Markets the Pinnacle API Covers in 2026

A straight reference: the 12 sports the Pinnacle API covers, the exact market types you get (money line, spreads, totals, team totals), what's behind the specials flag, and what it deliberately does n

Which Sports and Markets the Pinnacle API Covers in 2026

Quick answer: the Pinnacle API through pinnapi covers 12 sports, with the standard set of markets on each (money line, spreads, totals, and team totals), plus player props, team props, exact scores and futures behind an opt-in flag. Golf is the one real exception, and it is money-line-only. Everything below is the detail behind that sentence.

This is a reference page. Skim to the table you need.

The 12 sports

Each sport has a stable pinnapi sport_id, which is the integer you pass in requests. It is not the same number as Pinnacle's internal sport id, so use the pinnapi column.

Two of those rows catch people out. sport_id=7 is both rugby codes, union and league, under one id, so filter on the league string if you only want one. sport_id=10 is a grouped bucket, currently volleyball and handball, rather than a single clean sport. Treat it as "assorted" and read the league field.

The golf exception

Golf is the one sport that breaks the pattern: it is effectively money-line-only, head-to-head matchups and outright winners. Checked against the live API, a golf event returns a populated money_line and no real prices anywhere else. The catch is that a market key can still be present but empty: in the events pulled for this page, team_totals came back as { "home": {}, "away": {} }, the key there but the object empty. So the rule is not "golf has no other markets", it is "never assume a market key means there are prices under it". Read the contents, not the key. If your parser assumes every sport carries prices for all market families, golf is where it breaks.

The standard market types

Within an event's periods, prices are organised under these keys. These are the ones you parse on nearly every sport:

• money_line is the straight win market: { home, away, draw }. The draw field carries a price where the sport has one (soccer) and is null where it does not (tennis, basketball, golf).
• spreads are handicap lines, keyed by the handicap value: { "<hdp>": { hdp, home, away, max } }. The max is the maximum stake Pinnacle is showing at that line, which is a useful liquidity signal on its own.
• totals are over/under, keyed by the points line: { "<points>": { points, over, under, max } }. Remember the line belongs to the market, not the price: over 2.5 and over 3.0 are different markets, not a price change. That distinction is the single most common odds-parsing bug.
• team_total is a single over/under per team: { home: {...}, away: {...} }.
• team_totals is the plural: multiple alternate team-total lines per side. Note the singular-versus-plural naming; they are two different keys.
• meta is per-period metadata such as scores and max stakes, not a betting market but often what you want alongside one.

Decimal odds throughout. Convert to American or Hong Kong on the display layer only, and do your maths on the decimals. Full walkthrough of the payload shape in the odds data format guide.

Specials: props, team props, exact scores, futures

Beyond the standard markets, Pinnacle offers special markets. These are off by default and returned only when you pass include_specials=1. They come back as separate events joined to the main match by parent_id, with prices under a special_markets object.

The one behaviour to know: specials do not fire drop alerts. The drop stream watches main markets only. If you build on props, you poll them yourself. There is a dedicated walkthrough in how to pull Pinnacle player props.

What the Pinnacle API does not cover

Just as useful as the coverage list, and the part most comparison pages leave out. Through pinnapi you get one book's live and prematch prices, and deliberately not these:

• Other bookmakers. Pinnacle only, by design. If you need many books in one call, that is an aggregator, and the honest comparison is in the 2026 provider breakdown.
• Historical odds. Live and near-live only. No archive of closing lines to backtest against.
• Results and settlement. No graded-outcome feed. You bring your own results source.
• Player and team stats. Prices, not sports data. If your product needs both, the clean architecture is two feeds, and plenty of stacks run exactly that split.

None of that is a gap to apologise for. It is the shape of a single-book, latency-focused feed. Knowing what is out of scope before you integrate saves you discovering it three weeks in.

Live and prematch use the same fixtures

One detail that removes a whole class of bugs: a fixture keeps its id from prematch into live. You do not re-key anything at kickoff. The same event you tracked prematch carries its id straight into the live phase, so your joins hold. Pass phase (or the prematch endpoints) to choose which slice you want.

Takeaway

Twelve sports, standard markets on each (money line, spreads, totals, team totals), golf as the money-line-only exception, and specials behind include_specials=1 with no drop alerts. What is out of scope, other books, history, settlement, and stats, is out of scope on purpose. Build against the coverage that is there and you have a fast, sharp, single-book line with no surprises.