Skip to content
LACROSSE API

← Blog

Architecture

Building a Lacrosse Live Centre: Snapshot, Stream, Resync

24 July 2026 · 7 min read

A reliable live centre uses two delivery modes together. REST tells you the complete current state. WebSockets tell you what changed.

1. Discover the game

Request active fixtures from your server:

curl "https://lacrosse-api.com/v1/fixtures?status=in_progress" \
  -H "Authorization: Bearer lax_live_YOUR_KEY"

Keep the key off the client. Your server can cache this list for a short interval and serve every connected fan from one response.

2. Load an authoritative snapshot

Fetch GET /v1/fixtures/{id} for fixture context and GET /v1/fixtures/{id}/live for the current board. Record the response sequence and inspect:

  • meta.retrieved_at
  • meta.cached_at
  • meta.cache_age_seconds
  • meta.is_stale
  • meta.is_complete

Freshness is part of the product state. A stale board should not look indistinguishable from an actively updating one.

3. Mint a stream ticket

Your server calls POST /v1/realtime/tickets with the API key. The single-use ticket can then be passed to the browser without exposing the key.

Subscribe after the socket opens:

{"type":"subscribe","topics":["fixtures.live"]}

Apply deltas only in sequence order. Treat heartbeats as liveness signals, not game events.

4. Recover deliberately

Networks pause. Browser tabs sleep. Deployments interrupt connections. When a sequence gap appears or the server sends resync_required, discard assumptions and load a new REST snapshot.

This snapshot–delta–resync loop gives you speed without pretending a stream is a database. It also makes customer support easier: every visible state can be tied to a request ID, source time and cache time.

Read the streaming protocol or start a trial.

More from the blog