Settings
Three categories, and the set is closed. Each is read by code that knows its shape, so an
unknown category answers 404 rather than creating a new row.
| Category | Scope | Holds | Costs |
|---|---|---|---|
softswiss | Casino | That casino's provider backend URL, auth token and casino id | settings.read / settings.write |
webhook | Casino | Their result endpoint and signing secret | settings.read / settings.write |
lobby | Platform | The three lobby windows | Super-user |
Mail configuration is not a category. It is built during initialisation, so a saved document could never reach it.
Secrets never come back
Reading a document answers "<field>Set": true|false instead of the value. The value itself is
sealed at rest.
It does not clear it. The client could not have received the secret, so treating an absent field as "clear this" would let pressing Save wipe a working credential.
To change a secret, type the new one. To leave it alone, leave the field empty.
Credential groups are all-or-nothing
Filling in a backend URL but leaving the auth token blank is refused at the write, while an operator is still present to fix it.
Half configured, that casino would present the platform's credential to its own endpoint, which is the leak the grouping exists to prevent.
Saves take effect immediately
The resolver caches for 30 seconds but invalidates explicitly on save. With only a TTL, a save would stay invisible until the entry lapsed: the database correct, the running system still on the old credential, and nothing reporting an error.
The game allowlist works the same way. It is cached, but invalidated explicitly on save, so a change you make here is live immediately. A change made outside the console can take up to 30 seconds to appear. See Allowlist changes.
softswiss
The credential used to mint demo sessions for bot seats. It is per casino, because each has its own casino id and its own token.
Leaving it empty falls back to the platform's environment credentials, which means bot sessions are minted under your casino id rather than theirs. That is valid for a single-casino install and wrong for a multi-tenant one.
webhook
Where that casino's terminal results go, and the secret those requests are signed with.
A casino that resolves to no endpoint is skipped, never defaulted to the platform's webhook. Their backend simply never learns a battle ended, which is silent from their side, so confirm it during onboarding rather than at go-live.
lobby, platform scope
The three windows: how long a lobby accepts players, how long a battle may sit starting, and how long a run may take.
They are platform-scoped and super-user only, because they describe how this install runs a battle rather than a casino's credentials, and the lobby service is one service.
They take effect on the next battle, not the next deploy.
An untouched form field submits zero, and reading it literally would close every lobby the instant it opened.
The form, the resolver and the service each reject zero as a window independently.
What is not here
max_inflight_battles sizes a channel once, at construction. max_concurrent_users is frozen
into the admitter at boot. The Redis stream consumer is built at boot and loops.
Storing any of those would produce a screen that saves and changes nothing. Changing them is a redeploy on the platform's side. See What the host controls.