Replay

Replays let players (or regulators) review a past round — a recorded view of which numbers were called, what cards the player held, and how the round settled. They're served from a separate replay.lpmbackstagedevelop.com host. The flow is identical whether you're an aggregator integrator or direct.

Replays are for review, not reconciliation. The authoritative record of money moved is the wallet's credit call. See Source of truth.

Why replays exist

• Player disputes — "Did I actually win that round?"
• Regulatory review — many jurisdictions require accessible round history.
• Support tooling — your support team can resolve tickets faster.

Flow

1. Player (or your support agent) requests a replay
2. You call our POST /gamelauncher/replay with the roundid
3. We return a short-lived launch URL on the replay host
4. You open the launch URL in a new tab or embed it in an iframe
5. The replay UI renders balls drawn, cards, and outcomes

If you're embedding the replay in an iframe inside your casino UI, allow the replay host in your CSP frame-src. See CSP guidance.

Request shape

See POST /gamelauncher/replay.

Round record retention

Round records (the underlying data the replay reads from) are retained indefinitely today — no automatic expiry. Configurable retention windows are on the roadmap and can be set per operator on request once they land.

If a roundid doesn't exist (typo, wrong environment, future retention expiry, etc.), /gamelauncher/replay returns { "errorcode": 206, "errormessage": "Game not found" } (HTTP 404).

Replay URL lifetime

The URL we return from /gamelauncher/replay is short-lived: each one expires 10 minutes after issue. URLs are single-use and not cacheable — request a new one each time the player views the replay.

This is separate from round-record retention: the round data may live for a year, but the URL itself expires within minutes. Always request fresh.