Launcher API

These are the endpoints we expose. Aggregators and direct integrators both call the same surface. Authentication is HTTP Basic Auth on all endpoints.

POST /gamelauncher/play

Create a session and return a launch URL.

Request

{
  "operator": "casino_abc",
  "mode": "REAL",
  "gamecode": "live-bingo",
  "currency": "EUR",
  "language": "en",
  "externalsessionid": "sess_xyz_789",
  "playerid": "player_42",
  "brand": "brand_1",
  "channel": "web",
  "country": "MT",
  "ipaddress": "203.0.113.10",
  "testaccount": false
}

mode: "DEMO" uses the same shape — currency is still required. Note that DEMO doesn't change game behaviour today: the wallet is still called (see Mode).

Field reference

Required

Recommended

Optional (stored with the player session)

We accept and store these fields. Apart from displayname, the game doesn't use them yet.

Response

{
  "sessionid": "<our-session-id>",
  "launchurl": "https://bingo.lpmbackstagedevelop.com/?launchCode=<code>"
}

Each game has its own host, so the host in launchurl depends on the gamecode. Always use the URL exactly as we return it.

Behaviour

• Repeat calls: while the last launch code is still valid (10 minutes), calling again with the same operator, externalsessionid and currency returns the same sessionid and the same launchurl. After the code expires, the same call creates a new session with a new sessionid.
• Reusing an externalsessionid with a different gamecode while its launch code is valid is refused (see Errors).
• launchCode expires after 10 minutes. Until then it can be exchanged more than once (the iframe may reload while starting).
• The session record has a 24 hour absolute lifetime. It is not refreshed by activity; expiry is fixed at creation. The player token the iframe gets from the launch code lasts 1 hour; after that, a reload, a reconnect, or a slot spin needs a fresh launch URL.
• country and ipaddress are persisted on the session for audit. We don't enforce geo-rules from these fields.
• The currency you send must be in the configured currency list for that game instance. If it isn't, /gamelauncher/play returns HTTP 400 with errorcode: 101 and message "Currency does not match instance configuration". We give you the supported list at onboarding.

About /gamelauncher/resolve-launch-code

You may notice an unauthenticated POST /gamelauncher/resolve-launch-code endpoint in network traffic from the iframe. It is an internal frontend bootstrap call: the iframe exchanges its short-lived launchCode (which is itself the credential) for a session token before the game starts. Casinos do not call this endpoint and don't need to.

POST /gamelauncher/replay

Return a URL that renders a past round for player or regulator review.

Request

Only roundid is required. Other fields (language, timezone) are accepted but ignored today. Any finished round we sent to your wallet works, including slot spins (slots:<uuid>). A reversed round or a failed spin returns errorcode: 206.

{
  "roundid": "<round-id-we-issued>"
}

Response

{
  "launchurl": "https://replay.lpmbackstagedevelop.com/?launchCode=<code>"
}

The replay frontend exchanges the embedded launchCode for a session token internally; integrators do not need to interact with that exchange directly. From your side, simply embed the URL we return. Replay launch URLs expire after 10 minutes and must not be cached — request a fresh one for every viewing. See Replay for the full flow.

GET /gamelauncher/gamelist

Return the games your operator can launch right now. Slots are listed only if you get a game code per slot.

Request

GET /gamelauncher/gamelist?operator=casino_abc
Authorization: Basic <same login as /gamelauncher/play>

operator is required. It is the same value you send in /gamelauncher/play.

Response

{
  "games": [
    {
      "gamecode": "live-bingo",
      "name": "Bingo Live",
      "type": "bingo",
      "status": "active",
      "demoSupported": false,
      "thumbnailUrl": "https://assets.lpmbackstageprod.com/games/live-bingo/thumbnail.png",
      "currencies": ["SC", "GC"],
      "rooms": []
    },
    {
      "gamecode": "liveplay-bingo-gem-burst",
      "name": "Gem Burst",
      "type": "slot",
      "status": "active",
      "demoSupported": false,
      "thumbnailUrl": null,
      "currencies": ["SC", "GC"],
      "rooms": ["live-bingo", "bingo-on-the-beach"]
    }
  ]
}

Behaviour

• Every call returns the full list. A game that is missing has been removed or switched off for your operator.
• If we can't build the full list, you get an error (errorcode: 101, HTTP 500), never a shorter list. Keep your current list and try again later.
• Errors use the same envelope as /gamelauncher/play: bad or missing Basic Auth is HTTP 401 errorcode: 201; a missing operator is HTTP 400 errorcode: 101.

Errors

Launcher API errors use integer error codes, matching the standard seamless-wallet integration convention:

{ "errorcode": 101, "errormessage": "bad request" }

errormessage values you may see with errorcode: 101 on /gamelauncher/play:

Classify by HTTP status, not just errorcode. The two endpoints handle internal errors slightly differently: replay returns errorcode: 500 with HTTP 500; play returns errorcode: 101 with HTTP 500.

Note: this is different from the wallet-side error envelope used in direct integration, where the codes you return to us are strings (NOT_SUFFICIENT_FUNDS, etc.). Two separate surfaces, two separate code conventions.

Rate limits

We don't currently enforce a per-operator throttle on the launcher API. The only effective ceiling is the AWS API Gateway account-level default. Talk to us before sending sustained traffic above ~20 requests per second per operator so we can provision a dedicated usage plan if needed.

Versioning