Live betting odds API: build on a Pinnacle in-play feed

What a live betting odds API has to deliver

Live betting, also called in-play betting, begins after an event starts. Prices respond to the changing market and the information published by the sportsbook feed. For a software product, the difficult part is not rendering a red or green number; it is preserving the identity and status of each market while updates arrive at different times.

A live betting odds API is not a bet-placement API. PinnWire supplies current Pinnacle reference data for dashboards, alerting, model inputs, market monitors, and decision-support systems. Your application remains responsible for authorization, local rules, risk controls, any execution integration, and settlement.

Why PinnWire is the strongest fit for live Pinnacle data

PinnWire is built around one clear job: make current Pinnacle odds useful to your application. The product keeps the simple path simple, then gives you a higher-volume push path when your live workflow needs it. You can prove the REST feed with the public demo, move to a free trial, and select the transport that matches your workload.

This separation makes a live betting data system easier to reason about: REST is the source for a known snapshot, SSE is a focused alert stream, and WebSocket is the full update stream. PinnWire does not force every consumer to process full-feed volume when a current read or a drop alert is enough.

REST: current Pinnacle in-play snapshots

The fastest way to test a Pinnacle in-play odds API is a REST request. The compatibility endpoint below returns live markets for a sport. Use a real trial or paid key for ongoing application traffic; the public demo is intentionally small.

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

# Read generated_at on every response.
# Live state appears only when the feed publishes it.

For a single match, use GET /kit/v1/details?event_id=N&key=YOUR_KEY. For a client rebuilding after a dropped connection, fetch the relevant live snapshot again and replace the local view from that response. Do not keep making decisions from an uncertain, partially updated book.

Live state is useful, but defensive parsing is required

When available, the live response can include a match state and participant state. Soccer may publish a state and minutes; other sports can publish different fields. Iterate over fields defensively, display a clear “state unavailable” treatment if needed, and never invent a score or period from a missing property.

const url = "https://pinnwire.com/kit/v1/markets?sport_id=1&key=YOUR_KEY&fresh=" + crypto.randomUUID();
const response = await fetch(url, { cache: "no-store" });
if (!response.ok) throw new Error(`PinnWire HTTP ${response.status}`);

const book = await response.json();
console.log({
  generatedAt: book.generated_at,
  events: book.events?.length ?? 0,
  firstState: book.events?.[0]?.state ?? null
});

PinnWire uses decimal odds in the compatibility response. Match event ID, market key, period, side, points, and response freshness before joining an update to your own records.

SSE: detected live odds-drop alerts

If your live betting product cares about a price falling rather than every market update, PinnWire’s SSE surface is the cleanest option. /odds-drop is the live-only stream; each event is a detected price drop with market context and the no-vig reference field nvp.

curl -N "https://pinnwire.com/odds-drop?key=YOUR_KEY&min_drop=5"

data: {"type":"connected","id":"..."}
data: [{"event_id":123,"market":"spread","period":0,
        "side":"home","from_price":2.40,"to_price":2.26,
        "drop_pct":5.83,"nvp":2.31,"is_live":true}]

min_drop=N sets the percentage threshold for that connection; the floor is 1%. REST drop records use from and to, while SSE keeps its wire names from_price and to_price. Keep-alive comments are normal and should be ignored.

What an alert does not mean

A detected drop is movement, not a promise of value, execution, or market intent. Re-fetch the current market when your decision requires it, confirm that the exact contract still matches, check your own authorized executable price and limit, and store the alert timestamp. The nvp field is a no-vig reference estimate; it is not a guarantee.

Raw WebSocket: a real-time live odds feed for your own book

Choose PinnWire’s optional raw WebSocket when your application needs the complete update stream for selected live events. The connection begins with a subscription and a baseline snapshot, then receives continuous adds, updates, and deletes for the subscribed scope. It supports both live and prematch streams.

wss://pinnwire.com/ws?key=YOUR_KEY

// Send within 10 seconds of connecting:
{"type":"subscribe","streams":["live"],"sport_ids":[1,3],"event_ids":[1631005165]}

// Reply to the server heartbeat:
{"type":"pong"}

Sport subscriptions cover the events in that sport; event subscriptions can target up to 200 event IDs per stream. Every subscription is acknowledged, and matching events are returned in a snapshot before ongoing frames. Large snapshots can be split into chunks with seq and final markers.

import WebSocket from "ws";

const ws = new WebSocket("wss://pinnwire.com/ws?key=YOUR_KEY");
ws.on("open", () => ws.send(JSON.stringify({
  type: "subscribe", streams: ["live"], sport_ids: [1]
})));
ws.on("message", raw => {
  const msg = JSON.parse(raw);
  if (msg.type === "ping") return ws.send(JSON.stringify({type: "pong"}));
  if (msg.type === "snapshot") return rebuildBook(msg);
  if (msg.type === "live") return mergeUpdate(msg); // add/upd/del
});
ws.on("close", (code, reason) => scheduleReconnect(code, reason));

For exact merge rules, key records by rec.id and the market key, deduplicate on markets[i].version, and use the ld price channel as the live price. A reconnect receives a new snapshot; the server does not preserve your client session.

Freshness, suspensions, closures, and reconnects

Live markets can pause around a scoring event, injury, period boundary, correction, or any other feed-published state transition. Your client should model this explicitly. A suspended or closed market is not a valid zero-priced market, and a missing update is not permission to keep showing an old number as current.

• Check freshness: read generated_at on REST, and use last_odds_update_seconds_ago from health when feed activity matters.
• Respect status: a market with status !== "open", or a WebSocket delete, should leave the active book rather than become a fake price.
• Preserve optionality: render live state only when it is present; field names differ by sport and no universal score is promised.
• Resync after reconnect: reconnect with backoff, subscribe again, consume the snapshot, then resume updates from that known baseline.
• Watch the queue: the heartbeat’s buffered_max_bytes shows send-backlog headroom. A consumer more than 32 MB behind is closed as slow_consumer so it can reconnect and resync.
• Keep one connection per key: a newer WebSocket connection evicts the older one. Use one deliberate owner for each key and coordinate reconnects.

Reconnecting safely

A practical reconnect loop uses increasing delays with a cap, clears the old local book, resubscribes, waits for the snapshot, and only then enables downstream decisions. Record close code and reason. Code 1001 can indicate a stale connection or eviction; 1008 can indicate an invalid key, no subscription, or a plan without WebSocket access; 1011 with slow_consumer means the reader fell behind.

A production live-betting API pattern

For most teams, the best PinnWire implementation is a small layered consumer. It gives a model or UI a current answer without forcing every component to own a socket.

1. Warm a current snapshot. Fetch the live events your product needs with REST, persist the event and market identity, and record generated_at.
2. Choose the smallest push surface. Use SSE for detected drop triggers; use WebSocket for a local book or continuous features across selected sports or event IDs.
3. Normalize without losing source context. Keep sport, event, period, side, points, market key, version, state, status, and receive time with each update.
4. Gate decisions. Reject stale records, closed markets, incomplete contracts, missing required state, or a queue that is in recovery. Never silently substitute a placeholder.
5. Recover deliberately. On reconnect, rebuild from the snapshot and replay only new frames. Log reconnects, subscription acknowledgements, parse errors, and backpressure.

Rate limits and the demo

The public key=demo is a quick REST proof: it is shared and capped at 10 requests per minute and 50 per day, and it does not unlock SSE or WebSocket. Trial and Stream plans allow 20 requests per minute and 100 per day; Pro allows 10 requests per second; Pro plus drops adds SSE; Scale allows 30 requests per second. The raw WebSocket requires the add-on. See current PinnWire pricing before sizing a production consumer.