Basics

Third-party game engines use API V2 to interface directly with the hizi.io RGS. You can also use API V2 for a RGS-to-RGS integration. API V2 also provides a call for the hizi.io certified RNG.

You can interface to API V2 in two ways:

1. Subscribe to the hizi.io RabbitMQ message broker. Use it to receive messages and to send messages through RPC calls to the hizi.io message broker. hizi.io provides a set of NPM modules for communication through the message broker. For other programming languages, see https://www.rabbitmq.com/tutorials/tutorial-six-python.html.
2. Listen to a HTTP port to receive incoming calls. Use HTTP POST calls to send data to the hizi.io RGS.

hizi.io recommends the message broker. The message broker uses less system resources. It also improves scalability and failure tolerance. Use variant 2 (HTTP/2) for a RGS-to-RGS integration when the third-party RGS is not hosted by hizi.io.

Integration models and what each needs

There are two integration models. They have very different setup requirements:

	Classic RGS-to-RGS (the typical case)	hizi.io-hosted engine (direct engine integration / "RGS inception")
Where your game logic runs	On your own infrastructure	Inside the hizi.io RGS
Transport	HTTP/2 (variant 2 above)	RabbitMQ or HTTP/2
RNG	Your own certified RNG (pass results in rngResult)	hizi.io certified RNG via /getRandomResult
hizi.io local stack / core-docker / GitLab access	Not needed	Retired. This local-development setup path is no longer supported (see Local Development)
Certification	You run your own certification on your own infrastructure. hizi.io is not involved. You expose your certified file hashes via /certifiedfiles	Built and certified within the hizi.io stack

If you do a classic RGS-to-RGS integration, you only implement this HTTP/2 API on your own infrastructure. You do not need the hizi.io local stack, the core-docker project, the private Docker/NPM registries, or a GitLab (code.hoelle.games) invite. This API alone connects your RGS to hizi.io. Your certification is entirely your own responsibility. You run it yourself. hizi.io has no role in it (there is no hizi.io certification suite for you to obtain). The local-development/core-docker setup path is for building a game hosted inside the hizi.io engine (SaaS engine builders). hizi.io has retired this path. It is no longer a supported integration path.

RNG: which integrations need the hizi.io certified RNG?

The /getRandomResult call to the hizi.io certified RNG is relevant only when the game logic runs inside the hizi.io RGS. In this case, the game logic must obtain its randomness from hizi.io for compliance:

• Direct game engine integration hosted by hizi.io, or a partner RGS hosted within the hizi.io RGS ("RGS inception"), uses /getRandomResult.
• Classic RGS-to-RGS integration (your RGS runs on your own infrastructure, the typical case) does not use /getRandomResult. Keep using your own certified RNG (for example, a provably-fair one). Pass its results in the rngResult fields of the gameround calls. You run your certification on your own infrastructure. hizi.io is not involved. hizi.io provides no certification suite for it. No part of hizi.io expects /getRandomResult calls from such integrations.

See /getRandomResult for details.

Important notes

    All amounts in calls, payloads, and responses are in minor units (1/100 of the currency)
    Make all calls idempotent on the hashes passed

Information flow for game engines

Information flow for RGS-to-RGS communication

---