Pinnacle Odds API in 2026: What Exists Now

There is no public Pinnacle API anymore. Pinnacle shut down public access in July 2025, and every integration that pointed at it broke — the affiliate-style REST endpoints, the odds feeds people had wrapped in cron jobs for years, all of it. What remains in 2026 is a market of independent services that carry the same underlying market data. pinnodds is one of them, and this page is the honest map: what died, what a real replacement has to do, and exactly which surface to call for which job.

If you've landed here from a Stack Overflow thread or an old GitHub repo, read the first two sections and you'll know where you stand.

What actually closed in July 2025

Pinnacle's public-facing API access ended. That's the whole event, and it matters more than it sounds, because Pinnacle wasn't just another book in an aggregator's list. Pinnacle runs low margin, high limits, and tolerates winners — which means their line is the closest thing the market has to a consensus fair price. Sharp bettors and quant shops didn't use the Pinnacle API because it was convenient. They used it because it was the reference.

When that access disappeared, three things broke at once:

• Price discovery. No more no-vig baseline to compare soft books against.
• Limit information. Pinnacle publishes max stake per line, which tells you how much conviction sits behind a price.
• Movement detection. Steam and drop detection needs one trusted book moving first. Losing it made every "line moved" signal noisier.

Scraping the site is the obvious reaction and a bad idea in practice. You get rate-limited, you get stale snapshots, quarter lines drop out, and your model quietly trains on garbage during exactly the volatile windows you care about. Polling HTML is not a data pipeline.

What a real Pinnacle odds API replacement has to do

Four requirements, in order of how often people get them wrong.

Push, don't poll. Odds are an event stream, not a resource you GET. If you poll every 5 seconds you have made a decision: you will miss every move shorter than 5 seconds, and during in-play those are the ones with money in them. A credible feed pushes.

Carry every line, not the headline one. This is the single most common failure in "Pinnacle-like" data. A soccer total isn't just 2.5 — it's 1.75, 2.25, 2.75, 3.25. A handicap isn't just -1 — it's -0.75, -1.25, -1.75, -2.25. Quarter lines are where Pinnacle's pricing granularity actually lives, and a feed that rounds them away has thrown out the information you came for.

Expose limit and no-vig price. limit and nvp are the two fields that turn a price into a signal. Without them you have a number; with them you have a number plus how seriously the book means it.

Handle specials without drowning you. Player props, exact scores, futures, outrights — enormous payloads, and most consumers don't want them by default.

pinnodds is built against exactly that list. Same market data, pushed, quarter lines intact, one API key.

The surfaces, with a code example for each

Auth is one API key everywhere: header x-api-key: YOUR_KEY for REST and SSE, or ?key= on the stream URLs when you can't set headers (browsers, curl one-liners, some serverless runtimes). The key is also your login. Full reference lives in the docs.

REST: live and prematch markets

GET /kit/v1/markets is the workhorse. event_type switches between live and prematch. GET /kit/v1/details gives you the deeper view on a single event.

curl -H "x-api-key: $PINNODDS_KEY" \
  "https://pinnodds.com/kit/v1/markets?event_type=live"

For prematch odds there's a dedicated path so you can walk the tree cheaply: /kit/v1/prematch/fixtures for the schedule, /kit/v1/prematch/markets for market structure, /kit/v1/prematch/lines when you want the priced lines themselves. Pull fixtures once, subscribe for the rest.

WebSocket: the raw passthrough

/ws/feed is the unfiltered stream — the same message flow that drives everything else, handed to you without opinion. Use this when you're building your own book of prices in memory and you want to own the merge logic.

import WebSocket from "ws";

const ws = new WebSocket("wss://pinnodds.com/ws/feed?key=" + process.env.PINNODDS_KEY);

ws.on("message", (buf) => {
  const msg = JSON.parse(buf);
  // maintain your own line book here; this is the raw feed, no aggregation
  console.log(msg);
});

ws.on("close", () => setTimeout(reconnect, 1000)); // always reconnect with backoff

One engineering note from experience: write the reconnect logic before you write the parser. Streams drop. A consumer that doesn't resubscribe cleanly will silently go stale, and stale odds are worse than no odds.

SSE: odds-drop alerts

/odds-drop (live) and /odds-drop-prematch (prematch) push an event when a market's price falls against its own recent history. Server-Sent Events over plain HTTP — no handshake ceremony, works through most proxies, trivially consumable.

import os, json, requests

url = "https://pinnodds.com/odds-drop"
headers = {"x-api-key": os.environ["PINNODDS_KEY"]}

with requests.get(url, headers=headers, stream=True) as r:
    for line in r.iter_lines():
        if not line or not line.startswith(b"data:"):
            continue
        e = json.loads(line[5:])
        print(e["sect"], e["outcome"], e["from_price"], "->", e["to_price"],
              "limit", e["limit"], "nvp", e["nvp"])

REST: the enriched drops view

GET /api/drops?mode=live (or mode=prematch) returns the same phenomenon in a different shape, and the difference is worth internalising because it trips people up:

So: the stream is fast and carries limit/nvp but makes you compute the percentage yourself. The REST row is the enriched, tidied version with drop_pct already done. Most teams use both — SSE to trigger, REST to display or backfill a dashboard.

Specials

Off by default, on with one flag:

curl -H "x-api-key: $PINNODDS_KEY" \
  "https://pinnodds.com/kit/v1/prematch/markets?include_specials=1"

Each special arrives as its own event row carrying special, special_category, special_markets and a parent_id that links back to the parent fixture. The reason it's opt-in is volume: soccer prematch is roughly 1,500 events without the flag and roughly 12,400 with it. Turn it on when you're indexing props; leave it off when you're watching match lines.

SDKs

npm install pinnodds
pip install pinnodds

Both wrap the REST and SSE surface, both are zero-to-low dependency. If you're prototyping, start here rather than hand-rolling the SSE parser — the framing edge cases are boring and already solved.

Where the depth and the push actually pay off

Two places, concretely.

In-play totals. A goal goes in, the total repriced three times in under a minute, and a poller sees one of those states — probably the wrong one. Push means you see the path, not a sample of it. And because quarter lines come through, you see 2.25 move before 2.5 does, which is often where the information appears first.

Cross-book screening. If you hold Pinnacle's nvp next to a soft book's posted price, you have an edge estimate rather than a hunch. Add limit and you can rank which of your candidate bets the sharp book is actually willing to absorb size on. That's the workflow the closed Pinnacle API used to serve, and it's the one worth rebuilding.

Where this feed is the wrong tool

Say it plainly, because a mismatched integration wastes weeks.

It's Pinnacle only. One source. If your product is an odds-comparison site that needs 40 bookmakers in a grid, you need an aggregator, not this. Some teams run both — pinnodds for the sharp reference, an aggregator for breadth — and that's a legitimate architecture, not a compromise.

There's no historical odds archive. This is a live and prematch feed. If you need three seasons of closing lines to backtest a model, pinnodds won't hand it to you; you'd have to start recording today and wait. Plan storage from day one if history matters to you — capture /ws/feed to your own store from the first hour.

Drop alerts are not predictions. /api/drops and the SSE streams detect that a price fell against its recent history. That's a mechanical fact, not a forecast. Plenty of drops are noise, limit adjustments, or a correction of an earlier bad line. The signal is in combining drop with limit and nvp, and in your own filtering — not in treating every alert as a bet.

Push access and rate limits are plan-gated. Line depth is identical on every plan — quarter lines, specials, all of it. What differs is your rate limit and whether you get push. Pro starts at $99/mo, Pro + SSE is $149/mo, Scale is $229/mo, with quarterly and semi-annual options on pricing. If you only need a nightly prematch odds pull, the entry plan is genuinely enough; don't buy streaming you won't consume.

If you want a betting bot, this is a component, not the product. No staking logic, no bet placement, no account management. It's data.

A sane integration order

Build it in this sequence and you'll avoid the usual rewrite:

1. Get a trial key (seconds, no card) and hit /health and /ping from your deploy environment. Confirm the network path before anything else.
2. Pull /kit/v1/prematch/fixtures and store your own fixture IDs mapped to pinnodds id values. Do this early — ID mapping retrofitted later is painful.
3. Add /kit/v1/markets?event_type=live on a slow poll just to eyeball shapes and prove your parser.
4. Switch the hot path to /ws/feed or /odds-drop. Keep REST as your reconciliation source, not your primary.
5. Only then turn on include_specials=1, and only for the categories you actually render.

Takeaway

The practical replacement for the closed Pinnacle odds API isn't a single endpoint — it's a split: /ws/feed or /odds-drop for the hot path, /kit/v1/* for structure and reconciliation, /api/drops when you want drop_pct computed for you. Remember that the SSE alert gives you limit and nvp but no percentage, while the REST row gives you drop_pct but not the stake ceiling. Consume both, key off quarter lines rather than the headline number, and record the raw stream from day one so you own a history nobody can close on you.