Pinnacle API access in 2026: what replaced the closed public API

Pinnacle's public API closed on July 23, 2025

The archived official documentation still states it plainly: "Access to Pinnacle API suite has been closed for the general public since July 23rd, 2025." Pinnacle's own article from the same day restates the policy: bespoke API access only, for vetted academic research initiatives and other approved sports betting related projects.

What that changes in practice: no self-serve signup, no new keys, and no new production integrations against the old suite. The pinnacleapi documentation repository remains online — OpenAPI specifications for the Lines API (v2), Bets API (v4) and Customer API (v1), plus a changelog, FAQ and fair-use policy — but treat it as a historical reference, not a route to access. Reading it is still worthwhile: it tells you exactly what a replacement has to match.

PinnWire is an independent data service. It is not affiliated with, operated by, or endorsed by Pinnacle — and neither is any other third-party feed.

Who can still get direct Pinnacle API access

The remaining direct route is Pinnacle's bespoke programme. The archived docs describe it as "bespoke data services for select high value bettors & commercial partnerships" and add that Pinnacle supports academics and pregame handicapping projects. To apply, you email a short description of your use case to [email protected] and the team replies with options.

Two practical points if you are weighing that route. First, it was never purely a data contract: the old suite required a funded Pinnacle account and HTTP Basic authentication, so access was an account relationship rather than an API key you could mint. Second, access was restricted to a maximum of 2 distinct IP addresses per client. If you are an academic group with a genuine research use case, the email is worth writing. If you need prices flowing into your app this week, it is not a path — plan for an independent feed instead.

What the old API required, and the limits a replacement has to clear

The old suite was more than an odds feed — it was a full betting API with three parts. The Lines API served fixtures and odds with a snapshot-then-delta pattern: fetch the current state first, then request changes since the previous response's last value. The Bets API handled placement and settlement, and the Customer API handled account data. A modern odds feed replaces the first part; if your product places bets, that is a separate system, not something a data API should fake.

The operational constraints are the part most replacement pages skip. Odds endpoints were rate-limited to 1 request per 2 minutes per endpoint per sportId, the sports list to once per hour, and clients were told not to loop endpoints per league or fixture but to batch leagueIds and eventIds into a single call. Two IP addresses was the ceiling. Those constraints are a realistic baseline for what your replacement needs to beat:

PinnWire's own answers to those four rows: REST snapshots for live and prematch, since for incremental reads, a trial key with 20 requests per minute and 100 per day, and paid plans with published request rates instead of per-request billing. The details are in the API documentation.

Five checks before you build on a Pinnacle feed

Once you accept that an independent feed is the practical route, the question becomes which one. These are the five checks that separate a feed you can build a model on from one you will be debugging for months. They apply to PinnWire as much as to anyone else.

1. Single-book or averaged? An aggregator blends several sportsbooks into one price. That is a different measurement from Pinnacle's own line, and if your model is calibrated against the sharp book, an average quietly moves the target. verify: the docs name one book per price, and no response field holds a multi-book consensus.
2. A freshness signal you can assert on. A cached response with no timestamp is indistinguishable from a live market. You want a generation timestamp on every payload and an age value you can alert on. verify: call the health endpoint twice, 60 seconds apart; both the timestamp and the age must move.
3. Push delivery that matches your workload. REST for boot and reconciliation, SSE for price-drop alerts, a raw WebSocket when your state book needs every subscribed update. A polling-only feed drags you back toward the old 2-minute trap. verify: transport limits and reconnect rules are documented, not just "WebSocket supported".
4. Flat pricing with published limits. Per-request metering makes your bill scale with market volatility. A flat plan with a documented request rate is easier to model and to test against. verify: a plan table lists request rates per tier and a shared demo key exists for smoke tests.
5. A first request you can run before you commit. The last check is empirical. Run one request, read the fields, compare them to the docs. If the shape or the freshness does not convince you, keep looking. verify: the next section — two commands against a live key, output included.

First request: a real transcript from the demo key

The fastest way to judge any feed is to run it. The public demo key needs no signup and is shared across all visitors, so it is for shape checks like this one, not for production. Both commands below were run from a plain shell on September 17, 2026, and the output is pasted exactly as it came back.

1. Check the feed's heartbeat first

curl -sS "https://pinnwire.com/v1/health?key=demo"

{"status":"ok","generated_at":"2026-09-17T10:17:07.086Z","last_odds_update_seconds_ago":0,"events_in_store":24129,"upstream":{"frames":2898115,"connects":9,"lastFrameTs":1789640226995},"ws_clients":2}

Two values matter before anything else. last_odds_update_seconds_ago is the age of the newest odds frame — 0 seconds at capture, meaning the feed was live at that instant, not serving a warmed cache. events_in_store was 24,129 events across the book. Set an alert on that age value before you set anything else: a feed that goes stale silently is worse than one that fails loudly.

Two real health calls, 95 seconds apart: the freshness age never left 0 while 2,136 upstream frames were processed.

2. Pull a live snapshot and parse it

curl -sS "https://pinnwire.com/kit/v1/markets?sport_id=1&key=demo"

{"sport_id":1,"last":1789640228183,"generated_at":"2026-09-17T10:17:08.183Z","events":[{"event_id":1636748795,"sport_id":1,"league_id":1709,"league_name":"AFC - Champions League 2","home":"Machida Zelvia","away":"Svay Rieng","starts":"2026-09-17T10:00:00Z","start_ts":"2026-09-17T10:00:00Z","event_type":"live","is_have_odds":true,"is_have_periods":true,"periods":{"num_0":{"number":0,"money_line":{"home":1.116,"draw":7.09,"away":14.25},"spreads":{"-2.75":{"hdp":-2.75,"home":2.2,"away":1.602,"max":1000},"-3":{"hdp":-3,"home":2.23,"away":1.585,"max":1000},"-2.5":{"hdp":-2.5,"home":2.06,"away":1.685,"max":1000},"-2.25":{"hdp":-2.25,"home":1.847,"away":1.87,"max":1000},"-2":{"hdp":-2,"home":1.625,
[trimmed — the full response was 7,460 bytes]

That is a live soccer market with a full line ladder, not a fixture list. Now the part that tells you whether the field names are sane enough to build on. This zero-dependency Node script reads the live market above and prints one spread with its freshness metadata:

const snapshot = await fetch("https://pinnwire.com/kit/v1/markets?sport_id=1&key=demo")
  .then((r) => r.json());

const event = snapshot.events.find((e) => e.periods?.num_0?.spreads);
const spreads = event.periods.num_0.spreads;
const line = Object.keys(spreads)[0];
const spread = spreads[line];

console.log({
  generated_at: snapshot.generated_at,
  last: snapshot.last,
  fixture: `${event.home} vs ${event.away}`,
  event_type: event.event_type,
  line: spread.hdp,
  home: spread.home,
  away: spread.away
});

{
  generated_at: '2026-09-17T10:17:06.626Z',
  last: 1789640226626,
  fixture: 'Machida Zelvia vs Svay Rieng',
  event_type: 'live',
  line: -2.75,
  home: 2.2,
  away: 1.602
}

The same fixture, the same line, parsed end to end. The fields worth understanding before you write your adapter:

• generated_at — when PinnWire generated the response. Assert on it; never trust a snapshot without it.
• last — the same moment as epoch milliseconds. Pass it back as &since= on the next call for an incremental read, then reconcile with a full snapshot after any reconnect.
• event_type — live or prematch. Live events can also carry a sport-specific state field.
• periods.num_0 — full-match markets. Later periods appear when Pinnacle publishes them; do not assume a fixed ladder.
• money_line — decimal home / draw / away. The draw is absent on two-way markets like tennis.
• spreads and totals — keyed by handicap and by points, preserving quarter lines as numbers. max is the market's reported maximum-risk context for that line when the market publishes it — not your account limit and not a promise of execution.

The timeline above is the freshness check executed rather than described: 95 seconds apart, the age held at 0 while the frame counter advanced. Run the same pair against your own key before you trust any feed. If you want this data in a chat client instead of curl, the MCP connector exposes read-only tools over the same feed.

Limits to plan around

A Pinnacle reference is only useful inside its actual boundaries, and this one has several worth knowing before you build:

• Pinnacle only. A single-book feed is not a multi-book aggregator. Arbitrage or market-comparison products need at least one other venue's prices alongside it.
• Current data, not history. You get current snapshots and roughly three hours of detected drops. If you need backtests, line history or closing-line value, store snapshots yourself from day one.
• An estimate is not a guarantee. The no-vig fair price on a drop record (nvp) uses proportional normalization. It is a defensible baseline, not a discovered true probability and never a promise of profit.
• Data only. No bet placement, no balances, no settlement, and no account access of any kind.
• Coverage follows the market. Markets, props, periods and game state appear only when Pinnacle publishes them. "13 sports" does not mean every league and title in each.
• One WebSocket connection per key. A second connection evicts the first — plan your reconnect logic accordingly.
• Independence. PinnWire is not affiliated with or endorsed by Pinnacle. Use it as a data source, and validate anything you build on top of it.

The comparison page walks through the other feeds, and the WebSocket guide covers the push transports in depth if your workload needs them.

Pinnacle API access FAQ

Does Pinnacle have a public API in 2026?

No. Pinnacle's public API suite has been closed to the general public since July 23, 2025. Pinnacle still offers bespoke data services to select commercial partners, high value bettors and approved academic or pregame handicapping projects, who apply by emailing a short use-case description to [email protected].

Can I still get a Pinnacle API key?

Only through Pinnacle's bespoke programme, which is application-only and not self-serve. For a working key today, the practical route is an independent Pinnacle odds API such as PinnWire, whose free trial key needs no card and carries 20 requests per minute and 100 per day.

What replaced the closed Pinnacle public API?

Independent Pinnacle-first feeds. They relay current live and prematch Pinnacle prices over documented REST, WebSocket or SSE endpoints under their own keys and rate limits. Pinnacle does not operate or endorse them, so the checks on this page matter.

Is the archived Pinnacle API documentation still useful?

Yes, as a reference. The archived repository still holds the OpenAPI specs, changelog, FAQ and fair-use policy for the old Lines, Bets and Customer APIs. It shows what legacy integrations expected, but it is not access, and it will not get you a key.

How do I verify a Pinnacle odds feed is fresh?

Read a timestamp on every response and an age value on a health endpoint. On PinnWire, odds responses carry generated_at and last, and /v1/health reports last_odds_update_seconds_ago. Two calls 60 seconds apart should show both fields advance.

Did the old Pinnacle API have strict rate limits?

Yes. Its odds endpoints allowed 1 request per 2 minutes per endpoint per sportId, the sports list once per hour, and access was restricted to a maximum of 2 distinct IP addresses per client. A replacement should offer documented, higher limits without per-request metering.

Run the same two calls before you decide

If the bespoke route is not open to you, the practical first step is not a purchase — it is the transcript above, run against your own key. Swap demo for a free trial key, watch generated_at advance between calls, and compare the market shape against the docs. The migration guide covers the adapter work if you are replacing an old integration, and the drops API is the movement layer once the snapshot side is working.

Get a free trial key   Read the API docs