Validate on save
Schema validation runs on every config change and surfaces problems — missing reels, broken paytable entries, invalid feature refs — before they reach the API.
Config Editor
Cymba's config editor lets teams define and refine slot game mechanics in JSON, validate changes instantly, and see the math impact before anything ships.
API example
POST /api/v1/spin
Authorization: Bearer cy_live_...
{
"config": "my-reel-adventure",
"lines": 20,
"client_seed": "session-xyz"
}
{
"result": {
"round_id": "01JQ5K8X...",
"grid": [[3,1,2],[4,2,5],[1,3,1]],
"summary": {
"total_multiplier": 5,
"breakdown": {
"payline": 5
}
},
"config_hash": "f91a..."
},
"provably_fair": {
"server_seed_hash": "a3f1c8...",
"nonce": 7
}
}
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.
Cymba stores game configs as versioned JSON objects in the dashboard. The editor gives teams a structured interface to create, clone, and modify those configs.
On every save, the editor runs schema validation. That catches structural problems before they propagate: missing required fields, symbol references that do not exist in the symbol table, feature configurations that reference undefined mechanics, or paytable entries with impossible symbol counts.
Once a config passes validation, it can be sent to the playground immediately. The playground runs real spins against the API using that config, so teams can see grid outputs, win breakdowns, and feature triggers without writing any code.
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 editor 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.
That connection means changes to the config are immediately testable and their math impact is traceable.
Building a game config from scratch takes time. Cymba provides template configs for common slot patterns so teams can start with a working math model rather than an empty file.
Templates cover basic payline games, ways-to-win setups, scatter-triggered free spins, cascading reels, and other common mechanics. A team can clone a template, adjust the paytable and reels to match their design, validate, and spin within minutes.
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.
Start with a free API key, clone a template, and run your first provably fair spin.