Skip to content
Pre-launch, play-money platform. No gambling operating licence in any jurisdiction, no live payment processor, no operator in production. Everything stated on this site is something you can check.
Live demos Request a demo

Product overview

One regulated core. Everything else is a client of it.

The money, the randomness, the limits, the personal data and the authentication live entirely inside the platform. Your website holds a bearer token and renders what the API returns — which keeps your web stack out of the part of the audit that hurts.

The boundary

Why the split is drawn exactly here

Every critical system a regulator or an ISO 27001 auditor cares about — the wallet ledger, RNG, financial limits, PII, authentication, the audit log — sits behind the API. The presentation layer stores none of it. That is not a performance decision; it is a scope decision, and it is worth real money at audit time.

Operator back office Player front end Mobile / partner Your own tooling One HTTP API — 308 operations across 268 documented paths bearer token · per-request tenant resolution · OpenAPI 3.1, regenerated on every route change 139 domain services · 66 models · 81 migrations wallet ledger · odds & settlement · bonus engine · compliance gates · audit log · tenancy scope
The same operations serve the operator console and the player front end. A front end is replaceable and the API is the product — which is why two of our own demo brands share zero front-end code and still run on one backend.
  • Your marketing site stays yours. WordPress, Next.js, a native app, or all three at once — they are HTTP clients, and swapping one does not touch the ledger.
  • Static-first is possible. Because every widget is an empty shell hydrated over AJAX, a customer site can be a static export that loads instantly and pulls live data from the API. Two of our demo brands are exactly that.
  • Audit scope shrinks. The systems in scope are the ones behind the API. A CMS that renders a balance it fetched is not storing a balance.

What is in the core

The regulated middle

Wallet & ledger

Append-only double-entry transactions. Every stake, settlement, deposit, withdrawal, bonus grant and adjustment is a ledger row with a reason, an actor and a timestamp. Balances are derived, never edited.

Sportsbook

Multi-provider odds ingestion with pluggable pricing strategies, bet builder correlation, system bets, live settlement from a results feed, and a liability sweep every 5 minutes.

Casino engine

31 in-house engines, provably fair by commit–reveal, RTP solved from the paytable, plus tournaments, jackpots and a seamless-wallet protocol for third-party content.

Compliance gates

Deposit, loss and spend limits with cooling-off, reality checks, self-exclusion, affordability signals, markers of harm, and GDPR export and erasure — each as a code path with tests, not a policy page.

CRM & bonuses

Segments, automation journeys, campaigns with consent enforcement built in, a bonus engine that allocates wagering rather than broadcasting it, loyalty tiers and affiliate attribution.

Identity & audit

Player and staff authentication, RFC 6238 two-factor at three levels, a role model with per-brand ownership boundaries, and back-office writes audited by default rather than by memory.

Integration

What day one actually looks like

STEP 01

Get a token

A bearer token and a tenant identifier. Everything after this is HTTP — there is no SDK you are forced to adopt and no proprietary transport.

STEP 02

Read the spec

The OpenAPI 3.1 file describes all 308 operations. Generate a client in your language from it; we did not write that client for you and you do not need us to.

STEP 03

Render something

Drop in the widget layer to get a working front end in an afternoon, or ignore it entirely and build your own against the same calls. Both are supported paths, not a fallback.

STEP 04

Go live per brand

A brand is a single re-runnable command, then a 30-day trial starts automatically. Content, staff and branding are yours from that moment.

Where the honest edges areDay one is real; day thirty needs two things we do not have yet. A live payment processor — the driver contract is built and tested against a mock, and a real PSP is an implementation against it. And a live KYC/AML vendor — same shape, same status. Both are integration work against a tested seam rather than invention from zero, but neither is connected today and we will not describe a mock as if it were a processor.

See the boundary in practice.

The fastest way to understand the split is to watch one back office drive four visually unrelated brands. That takes about ten minutes on a call.

Request a working demo Read the API surface