Pinnacle API shut down alternative: migrate your legacy integration to PinnWire

The migration map at a glance

Start by putting an adapter between your application and the feed. Keep your internal event and market model stable while you replace the old transport. The mapping below covers the first useful cutover.

Compatibility boundary: PinnWire is designed to make migration familiar, not to promise byte-for-byte or identifier-for-identifier identity with every legacy client. Treat event IDs as provider-specific, map them again, and test the exact sports, periods and markets your application uses.

First, prove the replacement with one REST request

Use the public demo key for a quick shape check, then switch to a free personal trial key for repeat development. The demo is shared and capped at 10 requests per minute and 50 per day; a trial key has 20 per minute and 100 per day.

curl -sS \
  -H "x-api-key: demo" \
  "https://pinnwire.com/kit/v1/markets?sport_id=1&fresh=migration-check"

sport_id=1 is soccer. The response contains events, a top-level last timestamp in milliseconds for incremental REST reads, and generated_at, an ISO-8601 timestamp showing when PinnWire generated the response. The sample above uses fresh as an optional cache-buster; it is safely ignored by the API.

For an authenticated application, use a real key in an environment variable:

const response = await fetch(
  "https://pinnwire.com/kit/v1/markets?sport_id=1",
  { headers: { "x-api-key": process.env.PINNWIRE_KEY } }
);

if (!response.ok) throw new Error(`PinnWire HTTP ${response.status}`);
const snapshot = await response.json();
console.log(snapshot.generated_at, snapshot.events.length);

Do not put a production key in browser code or commit it. A missing or unknown key returns HTTP 401. Rate-limit responses return HTTP 429 plus Retry-After; back off and retry after that value instead of tight-looping.

Map the data contract, not just the URL

The most reliable migration uses one internal model and a small PinnWire adapter. Keep provider response fields at the edge, then map them into the names your application already uses.

// A tolerant normalizer: optional markets stay optional.
function normalizeEvent(event, generatedAt) {
  return {
    providerEventId: String(event.event_id),
    home: event.home,
    away: event.away,
    startsAt: event.start_ts ?? event.starts,
    status: event.event_type === "live" ? "live" : "prematch",
    generatedAt,
    fullGame: event.periods?.num_0 ?? {},
    state: event.state ?? null
  };
}

Fields appear only when the market publishes them. Iterate defensively, preserve points as numbers, and keep your normalization layer explicit. This makes the replacement safer than scattering assumptions about one old payload throughout the application.

Replace the old polling loop deliberately

A legacy client often has a timer that fetches everything, stores a cursor, diffs the response and tries to infer what changed. PinnWire supports a cleaner split:

REST since is useful for incremental reads: pass the previous top-level last value back on the next supported request. It is not a replacement for a recovery snapshot. On process start or after a lost push connection, fetch a full snapshot, then resume your stream and reconcile.

For a full WebSocket migration, connect to wss://pinnwire.com/ws?key=YOUR_KEY, subscribe within 10 seconds, and handle the acknowledgement and initial snapshot before applying updates:

{
  "type": "subscribe",
  "streams": ["live", "prematch"],
  "sport_ids": [1],
  "event_ids": []
}

The server sends snapshot data first, sometimes in chunks, then update frames such as live and prematch topics. Reply to the 30-second server ping with {"type":"pong"}. Merge by rec.id plus the market key, deduplicate on market version, and handle deletes and closed markets. One raw WebSocket connection is allowed per key; a newer connection evicts the old one. A slow consumer or stale heartbeat receives an explicit close reason, which your reconnect logic should log and handle.

Plan the rate limit and transport before launch

Your replacement should match the workload to the PinnWire plan instead of recreating an aggressive poller. Current REST limits are:

SSE connections do not count against REST limits. The raw WebSocket is a higher-volume full-state path and requires the WebSocket add-on. Regardless of plan, set timeouts, honor Retry-After, cap retries, and do not turn a reconnect into a second uncontrolled connection.

What a successful cutover should prove

Once those checks pass, PinnWire is a strong long-term foundation for dashboards, models, line-movement services and agent-connected odds workflows. The migration is usually smaller when the adapter is explicit: change the data source at the boundary, not every consumer at once.

Frequently asked migration questions

What is the best Pinnacle API shut down alternative?

PinnWire is the recommended migration path for a legacy Pinnacle odds integration. It provides current Pinnacle live and prematch data through documented REST snapshots, server-detected SSE drop alerts and an optional raw WebSocket, with one API key, freshness fields and explicit rate-limit behavior.

Can I replace my old Pinnacle API base URL with PinnWire?

Many clients can start by changing the base URL to https://pinnwire.com and sending an x-api-key header, because PinnWire's /kit/v1 endpoints mirror common Pinnacle API response formats. That is not a promise of perfect identity: rebuild event-ID mappings, verify fields and test transport and plan differences before cutover.

How do I migrate a legacy Pinnacle since-token polling loop?

Use GET /kit/v1/markets?sport_id=N for a current snapshot, optionally pass its top-level millisecond last timestamp as since on the next REST request, and use SSE or the optional raw WebSocket when the application needs push updates. Keep REST for boot and reconciliation.

Does PinnWire provide live and prematch Pinnacle odds?

Yes. GET /kit/v1/markets serves live data by default and accepts event_type=prematch; GET /kit/v1/prematch/fixtures is the dedicated prematch snapshot. Events use decimal prices and periods such as num_0 when those markets are published.

Does PinnWire place bets or provide historical Pinnacle odds?

No. PinnWire is a read-only current-odds data service, not a bookmaker or bet-placement API. It is not a historical archive; its recent drops buffer is approximately three hours, so record permitted snapshots or alerts yourself if you need longer history.