Beta testing Free API keys are open for testing. Paid tiers are waitlisted while we harden billing, legal, and audit workflows.

Config Editor

Design slot math in a wizard, not a JSON file

Cymba's slots wizard walks you from game shape to published config in four steps — symbols and glyphs, reels and paytable, features — with validation on save and live math feedback. Instant-win games get the same treatment in the Instant-Win Studio.

Four steps, whole game

Shape and recipe, identity and symbols, reels and payouts, features — every engine knob the API accepts is reachable in the wizard, no raw JSON required.

Validate on save, spin right away

Server-side validation runs on every save and surfaces problems readably — then any draft can be played in the dashboard playground without a deploy cycle.

Tied to the full toolchain

The config the wizard saves is the object the spin API resolves, the RTP calculator analyzes, and the PAR sheet exporter audits — one ID end to end.

API example

Spin a stored config

Request
POST /api/v1/play
Authorization: Bearer cy_live_...

{
  "config": "my-reel-adventure",
  "lines": 20,
  "client_seed": "session-xyz"
}
Response
{
  "result": {
    "round_id": "c47a90b81d2e...",
    "spins": [{
      "type": "base",
      "reel_positions": [["A","Q","K"],["K","A","J"],["Q","A","A"]]
    }],
    "summary": {
      "total_multiplier": 5,
      "breakdown": {
        "payline": 5
      }
    },
    "config_hash": "f91a..."
  },
  "provably_fair": {
    "server_seed_hash": "a3f1c8...",
    "client_seed": "session-xyz",
    "nonce": 7
  }
}

What belongs in a slot game config?

A slot game config is the complete definition of the math model for a game. It describes the reels, symbols, paytable, win mode, feature triggers, free-spin behaviour, and any caps or limits.

Change the config and you change the game. Swap a reel strip and you change hit frequency and expected value. Update a multiplier in the paytable and you shift how much a win pays. Add a scatter trigger and you introduce a feature path that contributes to RTP.

For that reason, config editing is not just a developer task. Game designers, math consultants, and product teams all need a way to understand, adjust, and verify game configs.

The slots wizard

Cymba's dashboard builds slot configs through a four-step wizard:

  1. Shape — pick a grid shape and optionally a recipe: a working math model for a common pattern (payline classics, ways-to-win, cluster, hold & respin) filtered to your shape.
  2. Identity — name the game, set the max-win cap, and build the symbol roster with the shared glyph library: per-symbol art, palettes, roles, and traits like scatter free-spin ladders.
  3. Math — reels with per-reel weights or drag-and-drop manual strips, the payout table, betting setup, and win-evaluation mode; advanced sections cover dynamic reels and symbol groups.
  4. Features — free spins with resolution effects, hold & respin, jackpots, meters, linked reels, nudge, gamble, and the rest of the feature surface, each with its own editor body.

Saving runs the engine's validator server-side. A draft that passes can be spun in the playground immediately, published to the API when ready, and re-opened for editing at any time — edit mode preserves the config ID so live spin logs stay tied to their math.

Instant games get a studio, not a form

The same design applies to instant-win games. The Instant-Win Studio is a visual editor for the eight instant mechanics: define the weighted prize pool, choose how the card presents it (scratch grid, wheel, dice duel, plinko board, pick field), and watch live RTP and Monte Carlo verification update as you edit. Studio configs flow into /api/v1/play, RTP tracking, and instant PAR sheets exactly like wizard configs do — one endpoint for both game types; the config picks the engine.

Why keeping config and math together matters

In a disconnected workflow, a game designer edits a spreadsheet, a developer transcribes it into code, and a math consultant eventually reviews the output. Errors accumulate at each handoff. A paytable row gets misread. A free-spin multiplier gets entered wrong. The config that shipped differs from the config that was designed.

Cymba treats the config as the single source of truth. The same config object the wizard saves is the one the API uses to spin, the RTP calculator uses to compute expected return, and the PAR sheet exporter uses to generate audit output.

Config versioning and the API

Every stored config has a unique ID. API calls reference that ID. If a config is updated, the old version can be preserved through a new ID so live spin logs remain tied to the config that generated them.

Config hashes in spin responses create an additional integrity layer. An auditor can compare the hash in a spin record with the hash in the exported PAR sheet to confirm that the spin used the expected math model.

Frequently Asked Questions

Do I have to use the wizard, or can I write JSON directly?

Both. The wizard produces the same config object the API accepts, and the spin API takes either a stored config ID or an inline config object — so you can iterate in code and manage in the dashboard, or the other way around.

What does validation catch?

Reels, row counts, symbol tables, paytable entries, win-mode settings, feature references, free-spin configs, max-win caps, and scatter trigger rules — with error messages written for game designers, not just engineers.

Can non-engineers build a game?

Yes — that's the point of the wizard. Shape pickers, recipe starters, a glyph library for symbol art, drag-and-drop reel strips, and payout tables replace hand-written JSON. Live math feedback shows the RTP impact as you edit.

What about instant-win games?

They have a dedicated editor: the Instant-Win Studio. Pick a mechanic (scratch, wheel, dice, plinko, pick), define the prize pool, and watch RTP update live — same validation-on-save, same playground, same API toolchain.

Ready to test Cymba?

Start with a free API key, clone a template, and run your first provably fair spin.