Works with any front end
Cymba is a JSON REST API. Any platform that can make an HTTP request can integrate it, regardless of front-end framework or game engine.
Online Slots
Cymba is an online slot API for studios and operators. Define your slot game in JSON, call the API, and receive a provably fair multiplier result. Your platform handles the player, the bet, and the payout.
API example
POST /api/v1/spin
Authorization: Bearer cy_live_...
{
"config": "neon-city-ways",
"lines": 243,
"client_seed": "usr-4912-round-88"
}
{
"result": {
"round_id": "01JR6W4K...",
"summary": {
"total_multiplier": 30,
"breakdown": {
"ways": 30
}
},
"result_hash": "7c4d19...",
"config_hash": "b3e8a2..."
},
"provably_fair": {
"server_seed_hash": "f12b7e...",
"client_seed": "usr-4912-round-88",
"nonce": 88
}
}
An online slot game has several layers: a front end the player sees, a platform that manages sessions and bets, and a math layer that decides what the spin produced.
Cymba is the math layer. It handles RNG, reel evaluation, win calculation, feature resolution, result serialization, and audit output. Your platform calls the API after a player places a bet and before it settles the outcome.
Your platform stores player session state, manages bet amounts, and controls the game front end. When a player spins, your platform calls Cymba with the relevant config ID and spin parameters.
Cymba returns the grid, win events, total multiplier, and provably fair fields. Your platform applies the multiplier to the player's bet to calculate the payout, stores the round record, and sends the result to the front end.
Cymba does not know the player, the stake, or the currency. It knows the config and the spin inputs.
Managing a library of online slot games is a config management problem in Cymba. Each game is a JSON config stored in the dashboard with its own ID, reel strips, paytable, win mode, and feature settings.
Adding a new game means creating a new config. Updating an existing game's math means editing the config, validating, recalculating RTP, and updating the config ID used in production. No backend code changes needed for mechanics already supported by the engine.
For an online slot library, RTP consistency matters. Players and operators expect games to perform within their advertised return range over sufficient volume.
Cymba's RTP tooling calculates theoretical RTP per config. The observed RTP endpoint tracks actual spin log data. Teams can monitor both across their full game library and flag configs that are behaving outside expected ranges.
Provably fair verification is included on every Cymba API key. The server seed hash is committed before spins are generated. Client seeds can be passed per spin. After seed rotation the previous seed is revealed, and prior spins can be replayed via /api/v1/verify.
For online platforms where player trust is important, this gives players a way to check specific spins rather than relying entirely on third-party certification.
Cymba is the math layer, not the online casino. Operators handle player registration and authentication, session management, bet placement and validation, payout settlement, transaction records, bonus systems, responsible gambling tools, licensing, and jurisdictional compliance.
Cymba's role is to resolve the spin and provide the verification material. Everything around the spin is the operator's product.
Start with a free API key, clone a template, and run your first provably fair spin.