Using Lacrosse Odds Without Losing Provenance

Sports state and market state are different evidence streams. They should meet in a product, but they should not be collapsed into one timestamp or one source.

Provider events are not fixtures

An odds provider publishes events, markets and outcomes using its own identifiers and labels. A lacrosse data source publishes league fixtures using league identifiers. Similar names and start times are useful matching evidence, but they are not proof.

Lacrosse API exposes provider events through GET /v1/odds/events. Use GET /v1/fixtures/{id}/odds when you need markets that have been verified against a particular lacrosse fixture.

Keep each observation time

A score observation has a source time. A market price has an observed time. The API cache has a cached time. Your own application has a received time.

Preserve them. A dashboard that compares a score and price without showing their relative age can imply simultaneity that never existed.

Treat labels as provider language

Keep provider, market and outcome labels alongside normalised identifiers. Do not silently rewrite an outcome into a team ID unless the relationship is verified. Decimal odds, implied probability and traded price are also distinct measures; expose the one you actually received.

Build the initial tape

1. Load the fixture and current score.
2. Request the fixture's verified odds.
3. Load GET /v1/odds/markets/{id}/prices for historical observations.
4. Subscribe to live market deltas when the product requires them.
5. Resync from REST after a gap.

Market data is informational and analytical context. It is not an official settlement source for wagering, contests or financial instruments.

Read the market data contract.