Synthetic Casino Data Platform
Realistic casino data, without a single real player.
Horus Lab creates tenant-scoped synthetic casino environments for developers, AI agents and iGaming teams that need realistic players, wallets, gameplay, source reports and postback-ready data without touching real player records.
The current Developer Sandbox contract exposes isolated instances, scoped API keys, synthetic run generation, data packages, proof packages and run-level cleanup for bounded test environments.
Who it is for Developers, AI agents, iGaming operators, CRM vendors, affiliate-platform teams and BI/data teams.
What it does
- Tenant-scoped sandbox instances
- Synthetic players, source paths and wallet ledgers
- Products Report and Players Report outputs
- Proof and cleanup by run lineage
Inside the Suite
A real product view
Why developers start with Horus Lab
Horus Lab solves a problem with no clean off-the-shelf answer: developers and AI agents need realistic casino data — players, wallet ledgers, gameplay sessions and source paths — without ever touching real player records. That makes it the most natural entry point into the suite for technical teams, because the data it generates is connected and report-ready instead of a flat sample file.
- It produces connected player, wallet, gameplay, event and reporting records, not isolated columns.
- It keeps a clear public explanation layer while instance data stays behind credentials.
- Its generated runs can later feed Horus Intelligence, Mock Casino and Viper validation workflows.
What a technical evaluator should understand
A developer should leave this page knowing that Horus Lab is not a static sample file. It is a controlled run system: create scope, generate data, inspect records, verify reports and clean up the generated run.
- Synthetic run data should be attributable to a tenant, workspace and run ID.
- Affiliate and organic source paths should stay separate until reporting contracts allow them to merge.
- Cleanup and proof packages are part of the product promise, not secondary admin tasks.
Connect and build in five steps
A developer or AI agent integrates against Horus Lab the same way it would against a real operator backend: authenticate, generate a bounded run, read the data and proof packages, then clean up. The data follows the horus_lab_developer_run_data.v1 contract, with operator-style Products and Players reports plus raw datasets for players, wallets, wallet ledger, game sessions and casino events.
- Step 1 - Create a sandbox instance: POST /api/horus-casino-lab/developer-instances returns a tenant-scoped instance and a one-time hl_sk_ API key.
- Step 2 - Generate a run: POST /api/horus-casino-lab/developer-runs with a player count, a day range and an organic or affiliate source mix.
- Step 3 - Read the data: GET /api/horus-casino-lab/developer-runs/{runId}/data returns reports, datasets and counts under horus_lab_developer_run_data.v1.
- Step 4 - Read the proof: GET /api/horus-casino-lab/developer-runs/{runId}/proof returns tenant isolation and collapsed technical evidence.
- Step 5 - Clean up: POST /api/horus-casino-lab/developer-runs/{runId}/cleanup removes only the run you created and leaves shared configuration untouched.
Why not a generic synthetic-data tool?
Generic generators can fake a table. iGaming integrations need cause and effect.
| Generic synthetic data | Horus Lab | |
|---|---|---|
| Connected casino journey | Isolated columns | Source to wallet to gameplay to report |
| Operator reports that reconcile | Not modeled | Products and Players Report |
| Affiliate / organic source paths | Not modeled | btag, click_id, attribution |
| Run lineage and one-click cleanup | Not modeled | Per run ID |
| iGaming-specific | Generic | Casino and operator workflows |
Product surfaces
These are the product names, modules and data objects used inside iGaming Suite today.
- POST /api/horus-casino-lab/developer-instances
- GET /api/horus-casino-lab/developer-access
- POST /api/horus-casino-lab/developer-runs
- GET /api/horus-casino-lab/developer-runs/{runId}/data
- GET /api/horus-casino-lab/developer-runs/{runId}/proof
FAQ
Who should evaluate Horus Lab first?
Developers, AI agents, BI teams, CRM vendors and operators that need realistic casino data contracts before connecting real operator systems.
Is Horus Lab a real-money casino?
No. Horus Lab is a synthetic casino data platform for testing, validation, demos and integration design.
How does Horus Lab help AI agents and search engines understand it?
The public pages expose clear entity language, API contract names, data artifacts, limitations and links to research, docs and glossary pages.