Developer Docs
Horus Lab Developer Sandbox Documentation
Public developer overview for Horus Lab sandbox identity, API key scope, run generation, data packages, proof packages and cleanup behavior.
The documented endpoints match the current Developer Sandbox v1 contract and are intentionally bounded for safe synthetic test data.
Who it is for Developers and AI agents evaluating synthetic casino data contracts.
What it does
- Create a developer instance
- Inspect agent-readable access manifest
- Generate bounded synthetic casino runs
- Retrieve data, proof and cleanup endpoints
Inside the Suite
A real product view
Sandbox workflow
The public sandbox documentation should let a developer understand the full loop before they ever create a private run. That loop starts with an isolated developer instance, continues through a one-time scoped API key, generates bounded synthetic casino data, inspects a data package, inspects a proof package and ends with cleanup by run lineage.
- Create a developer instance with tenant and workspace scope.
- Read the access manifest to understand auth, endpoints, examples and success criteria.
- Generate a bounded run with synthetic players, source paths, wallet rows, gameplay and casino events.
- Retrieve data and proof packages for downstream validation.
- Cleanup by run ID so generated test rows do not become permanent product truth.
What the sandbox is built to prove
This page answers the integration questions generic iGaming pages skip: how the data is scoped, what records exist, how proof is delivered, and how a test can be repeated or removed. A developer should be able to judge fit before writing a line of code.
- Whether a run can represent both organic and affiliate source paths.
- Whether wallet, gameplay and report outputs can be inspected together.
- Whether downstream systems can validate Products Report and Players Report shapes.
- Whether AI agents can read the public contract without receiving private credentials.
What the sandbox documentation should prove
A developer should be able to inspect this page and understand the lifecycle: create an instance, request a scoped key, read the manifest, generate bounded run data, fetch proof and clean up the run. That lifecycle is the difference between a serious sandbox and a static example file.
- Access manifests tell agents what they can read before private API work.
- Run data and proof packages keep generated records tied to explicit lineage.
- Cleanup endpoints prevent synthetic test data from becoming unmanaged product debt.
Product surfaces
These are the product names, modules and data objects used inside iGaming Suite today.
- Authorization: Bearer hl_sk_...
- horus_lab_developer_access_manifest.v1
- horus_lab_developer_run_data.v1
- horus_lab_developer_run_proof.v1
FAQ
What is the first thing a developer should understand?
The sandbox is scoped by developer instance and API key. Public docs describe the contract, while private run data requires authorization.
What makes Horus Lab different from a static sample dataset?
Horus Lab models run lineage, source paths, wallet ledgers, gameplay sessions, report outputs, proof packages and cleanup, so integration tests can exercise a workflow instead of a single CSV.
Can an AI agent use the sandbox safely?
An AI agent can read public docs and manifests, but private sandbox actions still require scoped credentials and should remain bounded by run limits and cleanup controls.