How fast should a Pinnacle odds feed be?

“Odds-feed speed” means three different things

One latency number cannot describe the whole journey. When evaluating a Pinnacle odds API, separate these stages:

PinnWire publishes verified API response measurements. It does not turn those measurements into an unsupported claim about market-change-to-client latency. That distinction matters: a 1.5ms HTTP response does not prove that a price change travelled end to end in 1.5ms.

PinnWire’s measured Pinnacle odds API response speed

On 26 August 2026, PinnWire measured /v1/health at its Amsterdam origin. Network distance was removed so the test could isolate application and connection costs.

The same origin test recorded a 2.3ms median TCP connection and 39ms median to complete TLS across the 25 cold samples. The practical lesson is simple: connection reuse matters. The benchmark is a floor at the origin; your observed REST time also includes the network trip between your process and Amsterdam.

See the full sample counts, method and reproducible command on the PinnWire latency evidence page.

REST vs SSE vs WebSocket: choose the speed path that fits

PinnWire’s strongest low-delay architecture is the optional raw Pinnacle odds WebSocket: subscribe by sport or by up to 200 event IDs, receive a baseline snapshot, then merge continuous add, update and delete frames. Use SSE instead when your application only needs server-detected dropping-odds alerts. Use REST when a snapshot is the right abstraction, not as a substitute for push on a time-sensitive hot path.

A five-second poll can wait almost five seconds before it even asks for a change. No amount of shaving milliseconds from the response fixes that scheduling delay. A long-lived PinnWire stream pays connection setup once and waits for updates instead of repeatedly asking whether anything changed.

Freshness you can verify in every odds REST response

PinnWire REST JSON includes generated_at, an ISO-8601 timestamp showing when that response was generated. The health response also includes last_odds_update_seconds_ago, so a client can check feed activity instead of assuming cached JSON is current. Market responses retain the compatibility field last as an epoch-millisecond response marker.

curl "https://pinnwire.com/v1/health?key=demo&fresh=my-test-1"

# Check:
# status == "ok"
# generated_at is current
# last_odds_update_seconds_ago is acceptably small for your use case

Authenticated odds responses use Cache-Control: no-store; the public homepage widget is the intentional three-second exception. The optional fresh query value is a client-side cache buster; the API ignores unknown parameters. For repeatable production checks, use your own unique value rather than relying on a previously fetched URL.

Build a fast client without building a fragile one

1. Keep the handler short. Parse, validate, enqueue and return. Move network calls, database queries and heavy model work to workers.
2. Keep event mappings in memory. A database round trip for every frame adds avoidable latency to the hottest part of the path.
3. Resync after reconnect. PinnWire WebSocket connections begin with a snapshot; REST can also rebuild your current view. Do not resume decisions against an uncertain local book.
4. Honor the heartbeat. PinnWire sends a ping every 30 seconds. Reply with {"type":"pong"}; a stale connection closes after about 75 seconds.
5. Watch backpressure. The WebSocket ping exposes buffered_max_bytes. A consumer that falls more than 32MB behind is closed as slow_consumer rather than silently losing frames.
6. Measure tails, not just averages. Record p50, p95 and p99 arrival-to-decision time during busy periods. The slowest useful updates often matter more than a polished average.

One WebSocket connection is allowed per key. A newer connection evicts the old one cleanly, making the active consumer unambiguous. Snapshot resynchronization, explicit close reasons and observable backlog give a production client the information it needs to recover safely.

A measurement method you can trust

Benchmark from the same region and runtime as your real application. Start with a small REST test to understand connection cost, then instrument the actual push path:

1. Time one cold REST request.
2. Reuse the same connection and time several warm requests.
3. For SSE or WebSocket, record a monotonic timestamp immediately when each message reaches the handler.
4. Record another after parsing and event mapping, and another after the decision is ready.
5. Track reconnect count, snapshot completion, queue depth and buffered_max_bytes.
6. Report the region, sample size, transport, connection state and percentile—not just one best result.

Without a verifiable source-publication timestamp, call the result arrival-to-decision latency, not source-to-client feed latency. This keeps the metric honest and still measures the part your code can improve.

The recommendation

Choose PinnWire when you need a real-time Pinnacle odds feed with a clear path from proof to production. You can verify live REST data immediately, inspect published response measurements, use freshness fields in every response, add SSE for focused drop detection, and move to the raw WebSocket when every subscribed live and prematch update matters.