RuneCode RGS: integration guide

This guide is for the engineers of an operator (a casino or lobby that shows our games to its players) or an aggregator (a platform that fronts many operators) who want to offer RuneCode games. It describes the integration as it works, the SDKs that implement it, and what is live today versus what is still planned.

If you already integrate games through Stake Engine, read Engine operators first: the operator API and the wallet contract are the same, and moving over is mostly configuration.

The model in one page

Two parties and one rule decide everything.

The RGS (Remote Game Server, run by us) decides every outcome. It never holds player money.
The operator wallet (run by you) is the system of record for player money.
A 2xx from your wallet is a promise that the money is durably correct. If you are not sure, answer 5xx: the RGS retries, effectively forever, and every retry is safe because every money movement carries an id you use as an idempotency key.

There are three surfaces, and you build two of them:

Surface	Direction	You build	Where it is described
Operator API	you → RGS	calls to launch games and look rounds up	Launching games, Catalogue, Rounds and reconciliation
Wallet API	RGS → you	four endpoints on your side: balance, debit, credit, rollback	Implementing the wallet
Game API	player's browser → RGS	nothing: our game front ends talk to it	(internal; Engine-compatible)

Both directions are authenticated with Ed25519 signatures over the exact bytes of each request. You never share a secret: you give us your public key and we give you ours. See Authentication and signing.

What a round looks like

 your lobby                 RuneCode RGS                         your wallet
     │  POST /v1/game/url        │                                    │
     │  (signed, token T) ─────► │ stores T, mints a session          │
     │ ◄───── {url, fair} ───────│                                    │
     │  redirect the player      │                                    │
     │  to url (valid ~120 s)    │                                    │
     │                           │ player opens the game              │
     │                           │ ── POST /v1/balance {token:T} ───► │  (the session check)
     │                           │ ◄──────── {balance} ────────────── │
     │                           │ player spins                       │
     │                           │ ── POST /v1/debit  {round, id…} ─► │  stake taken
     │                           │ ◄──────── {debit_id, balance} ──── │
     │                           │ outcome drawn, round settles       │
     │                           │ ── POST /v1/credit {round, id…} ─► │  win paid (omitted for a loss)
     │                           │ ◄──────── {credit_id, balance} ─── │

The player's browser never sees your token: it only gets an RGS-minted session id inside a one-time, signed URL.

What you need

An Ed25519 key pair for each environment (openssl genpkey -algorithm ed25519). Keep the private key; send the public key.
A wallet endpoint, reachable by us, that implements four calls. We provide a reference wallet to start from.
The list of lobby origins that will frame the games (we restrict framing to them).
For production: licences per jurisdiction, and the onboarding steps in Testing and going live.

Where to go next

Quickstart: from zero to a launched game in your own environment, step by step.
SDKs: TypeScript, Python, Go, Java, Rust, PHP and C#. They sign requests, call the operator API and verify our wallet calls.
Availability: exactly what is live today and what is planned. Read this before you plan a schedule.