Discussions

Hi,

We are using the v3 odds and fixtures endpoints to power an in-play sportsbook integration, and we've noticed a recurring pattern that creates a real arbitrage exposure on our end. I'd like to ask whether this is expected behavior and what the recommended way to detect it is.

The issue

For some live fixtures (we've seen it across tennis, soccer and basketball), a market keeps returning the same price for several minutes — sometimes 4-5 minutes — even though the score on the pitch has clearly changed (goals, breaks, made baskets). During that window:

apiCurrentOdd.price stays unchanged
apiCurrentOdd.timestamp does not advance — it still reflects the price's last actual change, which can be 300-400 seconds in the past
The sportsbook's last polled time (/sportsbooks/last-polled) is fresh (a few seconds old), so from our side the sportsbook itself looks healthy
The fixture is still flagged is_live: true / status: "live"
The result is that the odd looks "current" by every signal we can read, but the underlying game state has materially moved. A user can place a bet at a price that no longer reflects reality.

What we've tried

We currently apply a stale-odd threshold (now - apiCurrentOdd.timestamp) and reject bets above it, but this is a blunt instrument:

Setting it tight (30-60s) generates many false positives in low-volatility markets (soccer pre-goal, baseball between pitches) where the odd legitimately doesn't move
Setting it loose (5-7 minutes) leaves the exposure described above
Questions

Is the lack of timestamp movement on an unchanged price expected? In other words, does apiCurrentOdd.timestamp reflect "last price change" or "last refresh from the sportsbook"? If the latter, it should advance with each poll even when the price is stable.
Is there a per-odd or per-market field that exposes a suspension / locked / inactive state we should be reading? We don't currently see one in the odds[] items but might be missing it.
On /fixtures/results, is there a way to get a per-score-event timestamp (e.g. last_score_change_at)? events is often empty for the sports we work with, and last_checked_at only reflects the freshness of the results payload itself, not the moment the score actually changed.
Is the recommended pattern to maintain our own score-change history and reject bets where lastScoreChangedAt > apiCurrentOdd.timestamp? Or is there a server-side signal we should be subscribing to?
Any guidance — including pointers to docs we may have missed — would be hugely appreciated.

Thanks!