What's What in the hizi app

The list below summarises the categories. In each section, you can find more information in the app itself. This overview is a summary only.

1. Games

This is the game catalog entry itself. It has a code, an origin (hizi-engine, Docker image, or your own RGS-to-RGS), and a status (draft or published). Only published games sync live. Permissions control which Partners or Identities may access it. Each game belongs to one Game Studio. Use this section to add and configure games, and to promote a build to production.

2. Game studios

This is the publisher entity (you can think of it as a brand) that owns games. It holds its own legal-entity info, geo rule, and per-game access permissions. It sits between the tenant and its Games. Set this up before you add games under it.

3. Hizi Engine Config

This is a stored hizi-engine build config. It holds the file location, publish lifecycle (in progress → publishing → published), and versioning. It is only relevant for games built on the in-house hizi engine, not Docker or external RGS. Studio staff use it to build and edit hizi-engine games. Launch the engine's own creator tool from here. Save the result as a config. The config then attaches to a Game.

4. Commercial Accounts

This is a billing or commercial-contact record. It groups together Partners or Identities that are commercially connected but otherwise separate. The in-app help text states that this feature is primarily for CRM teams. It is not yet fully implemented. Later releases will add more functionality for this module.

5. Partners

This is the top-level business relationship with a casino operator group. It holds a name and tier. It links to one Account and a Geo Rule. It is the parent of Identities and Legal Entities. Hierarchy: Partner → Identities → Games. Staff use it to onboard and manage an operator relationship.

6. Identities

This is a specific operator brand or casino site under a Partner. It has a code, tier, mode (production or staging), the site it runs on, integration protocol, and credentials. Games are access-controlled per Identity. An Identity can carry a Settings template, a Game Settings template, a Geo Rule, and a Billing Group. Use this section to configure each operator brand individually.

7. Identity Settings - Templates

This is a reusable preset of Identity-level settings. Create a template once. Apply it to any number of Identities. The template is live-linked, not copy-on-apply. When you edit the template, the system updates every Identity that uses it. Studio staff use this to keep many Identities configured consistently.

8. Identity Game Settings - Templates

This follows the same idea as Identity Settings, but for per-game configuration on an Identity. It has separate settings blocks for real play, demo play, and general game behaviour. It is also live-linked. When you edit the template, the system updates every Identity and game that uses it. Studio staff use this for consistent game-level configuration across Identities.

9. Integrations

This is a browsable catalogue of supported wallet and RGS integration protocols. It covers the native hizi protocol and third-party operator protocols, and their capability flags. It also has a per-Identity view of that Identity's live integration details (callback URLs, protocol settings), with a PDF export. Tenant technical and integration staff use it as a reference and to debug a specific brand's connection. hizi staff manage the underlying protocol definitions internally.

10. Legal Entities

This is the company record (name, address, VAT) required for invoicing. You can optionally link it to a Partner. Tenant finance and back-office staff use it.

11. Billing Groups

This section is a work in progress.

12. Game Launcher

This is a test-launch tool to verify a game's integration and try the gameplay. Launch with a real or test player. Launch a no-player demo. Or generate a shareable static demo link, for example to hand to an operator. Studio QA and integration staff use it.

13. Wallet test runner

This is a wallet-API simulator. Run a fixed suite of test cases (normal operations, tickets, failures, voids, protocol validation) against a chosen Identity with a fake player. View pass or fail results with full request and response logs, including ready-to-paste curl commands. Export a PDF report. Studio integration engineers use it to validate their wallet endpoint before going live, without real players or money.

14. Players

This is the per-tenant player wallet record. It has a name, code, balance, currency, and any discount or promo info. This is the wallet-side player account, linked to rounds and transactions, not the operator's own player identity. It sits alongside the wallet-testing tools. It is mainly a studio ops toolkit for managing test and demo player balances.

15. Freeplays

This is a promotional free spin grant tool. Pick a player and a game. Set the stake size the free spins use. Set how many to grant, plus an expiry. The tool tracks how many free spins have been used or won. Studio and ops staff use it to award free spins to a specific player on a specific game.

16. Transactions

This is the read-only wallet debit and credit ledger. It records every transaction against a player's balance (bet, win, void, and so on), with the balance before and after, the linked round, and freeplay ticket usage. Ops, finance, and support staff use it to reconcile what happened on a round. You cannot create or edit anything here.

17. Logs

This section is not a log viewer itself. Pick a Site (a regional server deployment). The system gives you the credentials and URL to log into that site's external logging tool (for example Graylog) yourself. Each Identity runs on a specific site. Technical and support staff use this section to trace an issue back to the right site's logs.

18. Audits

This is a genuine change-history trail. The system records every create, update, or delete action on tenant-managed entities (games, identities, partners, brands, settings templates, accounts, users, and so on). Each record shows who made the change and the values before and after. Anyone who needs to answer "who changed this and when" can use it: compliance staff, support staff investigating a dispute, or a studio admin reviewing team activity.

19. Stats

This is a historical KPI dashboard (revenue, rounds, players, and so on). You can filter it by date range, currency, operator (Identity), and game. The dashboard pulls data live from each RGS site your identities run on. It is not a fixed local report. Studio staff and management use it to track game and business performance.

20. Search gamerounds

This is the search form to look up gamerounds. Search by exact hash, or by advanced filters (player, game, operator identity, date range, status). It submits an asynchronous search job. Ops and support staff use it to start an investigation into a player's or game's round history.

21. Gameround search result

This is the results and per-round detail view for a search submitted above. It shows the status of the search, and a full forensic breakdown of one round (bet and win amounts, free spin usage, raw transaction data). Ops and support staff use it to reconstruct exactly what happened in a specific round, for example for a player dispute.

22. Publish

This is not a stored record. It is the "go live" action. The system saves everything you configure on Games, Identities, and Settings as a draft first. Publish pushes your published games (with their current version and per-Identity permissions) out to the operator sites. Use it as the final step after you set up everything else.

23. Sites

This is a deployed regional server (production or staging) with its own region, credentials, and URLs. It is the infrastructure an Identity runs on. Provisioning new sites is a hizi staff task. You only see a read-only list of the sites your tenant is entitled to use. You mainly use this list to pick a site when you publish.

24. Geo Rules

This is a named allow or deny list of countries and IP addresses. You can attach it to a Partner, Game Studio, Identity, or Game. One rule can cover several of them at once. It explicitly overrides any broader restriction set at the platform's Jurisdictions level. Studio compliance and ops staff use it to configure territory restrictions per operator relationship.

25. Docker Registries

Connect your own GitLab-based Docker registry here. Provide the registry or server URL, an access token, and which GitLab projects to scope and sync. This is the manual setup step. Everything below it auto-syncs from here. Use this section when you wire up your own GitLab, before you import games through a Docker image.

26. Docker Repositories

This is a read-only, auto-synced list of the repositories pulled in from an enabled Docker Registry. You do not create anything here manually. Use it to browse what is available from your GitLab before you pick an image.

27. Docker Images

This is a read-only, auto-synced list of the image tags within a repository. It is what you attach to a Game when its Origin is Docker image, through a Game's Docker version. Use it to configure which build powers a game.

Hierarchy: Registry (you configure) → Repository → Image (both auto-synced) → attached to a Game as a Docker version.