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.
Audience
Developers and AI agents evaluating synthetic casino data contracts.
Proof
The documented endpoints match the current Developer Sandbox v1 contract and are intentionally bounded for safe synthetic test data.
Limits
This public page explains the contract. Instance creation and run data require Suite access or an instance-scoped Horus Lab API key.
Product evidence
Visible product proof for humans and agents
Visible proof table
| Signal | Visible proof on this page | Discovery value |
|---|---|---|
| Audience | Developers and AI agents evaluating synthetic casino data contracts. | Connects the page to a real professional audience instead of generic iGaming traffic. |
| Proof | The documented endpoints match the current Developer Sandbox v1 contract and are intentionally bounded for safe synthetic test data. | Gives crawlers, AI retrieval systems and readers a concrete product claim to understand. |
| Limits | This public page explains the contract. Instance creation and run data require Suite access or an instance-scoped Horus Lab API key. | Builds trust by stating what the public page does not expose or prove. |
| Public contract signals | Authorization: Bearer hl_sk_... | horus_lab_developer_access_manifest.v1 | horus_lab_developer_run_data.v1 | horus_lab_developer_run_proof.v1 | Makes product APIs, data objects and entity names easy to parse and cite. |
What this page makes discoverable
- Create a developer instance
- Inspect agent-readable access manifest
- Generate bounded synthetic casino runs
- Retrieve data, proof and cleanup endpoints
Public contract signals
These names help humans, search engines and AI retrieval systems understand the product boundary without exposing private workspace data.
- Authorization: Bearer hl_sk_...
- horus_lab_developer_access_manifest.v1
- horus_lab_developer_run_data.v1
- horus_lab_developer_run_proof.v1
Search intent map
What professionals are likely to search
| Search language | Likely reader | Page answer |
|---|---|---|
| casino data sandbox API | Backend developers and QA engineers | Explains the instance, API key, run generation, data retrieval, proof retrieval and cleanup loop. |
| synthetic casino API for AI agents | Agent builders and AI evaluation teams | Names the manifest, scoped authentication and proof package that an agent can use to understand the sandbox safely. |
| mock casino data with wallet ledger | BI/data teams and CRM vendors | Clarifies that Horus Lab produces real-shaped players, wallet ledger rows, gameplay sessions and report outputs without real player records. |
| cleanup synthetic test data by run | Developers testing repeatable integrations | Makes run lineage and cleanup behavior a first-class contract, not an afterthought. |
Discovery rationale
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.
Discovery rationale
What the sandbox is built to prove
The page should rank for developer intent because it answers integration questions that generic iGaming pages do not answer: how the data is scoped, what records exist, how proof is delivered, and how a test can be repeated or removed.
- 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.
Discovery rationale
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.
Evidence discipline
Why this page is built this way
- web.dev agent-friendly site guidance Supports semantic, stable, labeled public pages that AI agents can parse and navigate reliably.
- Google structured data introduction Supports keeping structured data aligned with visible documentation rather than adding hidden claims.
Questions this page answers
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.