hizi.io -> Operator
This section describes the possible calls which can be made from the hizi.io backend to the operator backend. Please note that IP whitelisting might be in place.
getBalance - get a player’s balance
This call is used to query a player's balance at the operator. Note that two balances may be returned (real + bonus). Returning a bonus balance is optional and only required by certain legislation. In case a bonus balance is returned also the attribute “useBonusFirst” should be returned in order to display the usage of bonus or real money in case that is mandatory by legislation frameworks.
| GET /getBalance | get the balance of a player | ||
| request Parameters (URI parameters) | |||
| attribute | type | mandatory | notes |
| playerId | string | YES | ID that identifies the player at the operators site |
| currency | currency | YES | currency for which the balance should be returned |
| gameCode | string | NO | In case a game code is submitted, return freeplays and/or tickets allocated to that game/player. ID that identifies the game, same code as in getGameUrl call. See ticket / free play documentation for further information Appendix D - free plays and game tickets |
| externalSessionId | string | NO | Reference to a session id passed in getGameURL call |
| fields to sign (order is important) | |||
| secret + X-H-AUTH-ID + X-H-TIMESTAMP + playerId + currency + gameCode (if present) | |||
| mandatory request header fields | |||
| X-H-AUTH-ID, X-H-AUTH-SIG, X-H-TIMESTAMP | |||
| returned attributes | |||
| attribute | type | mandatory | notes |
| balances | array of playerBalance objects | YES | one or two entries can be returned, one of them has to be “real” money, “bonus” money might be returned optional |
| discountInfo | discountInfo structure | NO | Optional discount information, see Appendix E for details |
| useBonusFirst | boolean | NO (defaults to true) | true if bonus funds are to be used first, false if real money has to be used first. Note that this is just informational to be displayed in the games frontend if applicable by regulations |
| errorCode | errorCode | NO | in case an error occurred HTTP status should not be 200 and an additional error information can be returned |
| clientMessage | clientmessage | NO | defines a message box to be displayed in the game client. Can also be present when an error occurred. |
Sample call to query a player's balance
| Sample call, fields that have to be included in the signature are highlighted in red | Description |
| **GET /getBalance?playerId=1234567¤cy=**EUR | Ask for a EUR balance |
| Sample response (success) | Description |
| { "useBonusFirst": "true", "balances": [{ "type": "real", "amount": 12000, "currency": "EUR" }, { "type": "bonus", "amount": 8010, "currency": "EUR" }] } | Return a real money balance of EUR 120.00 and a bonus money balance of EUR 80.10 Bonus money has to be used first so the game would display a message “you are using bonus funds” if needed by legislation. |
| Sample response (error) | Description |
| { "errorCode": { "id": 1, "msg": "player id unknown" } } | Return an error that player id was not found. Note that this call should not return HTTP code 200! |
doTransactions - submit game transactions
This call is used to submit one or more transactions that happen in a game. All transactions refer to a gameround which is identified by a unique hash. Multiple transactions can be submitted in one call, however also multiple calls can happen. Each transaction is identified by a unique hash. This call has to be idempotent on these hashes.
Transactions should be processed in the order they are received, however a void operation for a debit transaction could be sent before the referred debit transaction is submitted, in that case the debit transaction, even if it is received after the void should be treated as voided.
If an error occurs in a debit transaction, subsequent credit transactions in the same request or the following requests should be declined and not processed. If at least one operation fails the HTTP return code should not be 200.
In case an initial debit request is received (isFirstDebit is set to true) and generates an error (like insufficient funds) the gameround should be treated as closed and no further debit / credit transactions should be accepted.
In case a follow up debit request is received (isFirstDebit is set to false) and generates an error (like insufficient funds) the debit transactions should not be performed, but the gameround should stay open and further debit / credit requests should be accepted. Note that you will never receive a debit request after an end command in a single call.
On return a player balance is expected indicating the new players balances after processing the transactions.
In case debit or credit transactions are received on a closed gameround and have not been processed before an error should be reported.
In case void calls are received they should be processed regardless of the state of the gameround.
Error handling for credit transactions
A credit transaction should never fail with a 5xx error. If it fails with a 5xx error it will be retried immediately. If further requests are failing it will be queued and retried in increasing intervals. Note that as long the credit call is not accepted the player won't be able to play the game as the gameround is still open. If a credit transaction is answered with a non-repeatable error previous debit transactions will be voided and the gameround will further be treated as voided.
If a previous credit transaction was successful, no debit and credit transactions should be voided and the gameround will be treated as crashed and should be reconciled.
List of actions that can be submitted
The following actions can be received in a transaction. You will always get at least one debit and one end transaction.
| action | notes | mandatory during lifetime of a gameround |
| debit | a player placed a wager (bet), if isFirstDebit is set to true this indicates the start of a new gameround | YES |
| credit | a player won an amount | NO |
| void | If a void call for a gameround is received no further calls should be processed / accepted and no end transaction is to be expected as the round will be marked as cancelledUpon receipt of a void call for a gameround, all subsequent calls must be rejected/ignored, and an end transaction should not be anticipated, as the round will be automatically marked as cancelled. Transactions submitted for a gameround that has been voided must be responded to with an HTTP status code of 400. | NO |
| end | The gameround is closed and no further transactions should be accepted unless void operations. Note that in case a VOID action was sent the end actions is not mandatory (although it could have been sent in a call with a combined debit + end transaction) | YES unless a VOID was sent |
Flows for transactions
The following diagrams should explain the handling of transactions.
Flow of a debit operation
Flow of a credit operation
| POST /doTransactions | submit an array of gameTransactions | ||
| request Parameters (JSON payload) | |||
| attribute | type | mandatory | notes |
| playerId | string | YES | ID that identifies the player at the operators site |
| gameCode | string | YES | ID that identifies the game played, same code as in getGameUrl call |
| gameRound | hash | YES | gameround that brackets all transactions |
| transactions | array of gameTransactions | YES | list of transactions that should be conducted, this array has to hold a least one entry |
| transactionCount | number | YES | count of transactions included in that payload, this should be the same as the length of the array of submitted transactions, If that differs the call should be rejected with an error code 400 and an error id 16 |
| serialUsed | string | NO | Contains the serial of ticket / freeplay package used for first deposit in this gameround. This is only set when there is no first deposit transaction in that call as the information will be contained in the field “serial” in transactions data. This field is supplied for informational purposes only to link credit + end transactions to a serial used if these are sent in separate calls. Note: This has to be activated by setting the flag “addSerialToTransactions” in the operator settings |
| ticketInformation | Object (see below) | NO | If a package of ticket / freeplays is finished in that gamerounds contains information about that ticket / freeplay like total amount won Note: This has to be activated by setting the flag “addSerialToTransactions” in the operator settings |
{ serial: string; stake: number; won: number; isFinal: boolean; used: number; } | |||
| externalSessionId | string | NO | Reference to a session id passed in getGameURL call Note: this property is only sent when originally passed to the RGS in the getGameURL call and the session is active. If the round is to be auto-closed by the RGS built in janitor there might not be a session active and therefore no externalSessionID is sent. The call should be processed regardless if an externalSessionId is sent or not! |
| fields to sign (order is important) | |||
| secret + X-H-AUTH-ID + X-H-TIMESTAMP + playerId + gameCode + gameRound + all transaction hashes and if applicable amounts submitted Fields to sign for transactions have always to be in the same sequence as they are submitted in transactions payload. See an example here for a debit/end and here for a debit/credit/end transaction E.g. hash of first transaction Amount of first transaction (no amount added if there is no amount or amount is 0 (zero) e.g. end or void operation or debit with a ticket supplied) Hash of second transaction (no amount added if there is no amount or amount is 0 (zero) e.g. end or void operation or debit with a ticket supplied) | |||
| mandatory request header fields | |||
| X-H-AUTH-ID, X-H-AUTH-SIG, X-H-TIMESTAMP | |||
| returned attributes | |||
| attribute | type | mandatory | notes |
| balances | array of playerBalance objects | YES | one or two entries can be returned, one of them has to be “real” money, “bonus” money might be returned optional. Balances should reflect the balance after processing the transactions. |
| discountInfo | discountInfo structure | NO | Optional discount information, see Appendix E for details |
| useBonusFirst | boolean | NO (defaults to true) | true if bonus funds are to be used first, false if real money has to be used first. Note that this is just informational to be displayed in the games frontend if applicable by regulations |
| errorCode | errorCode | NO / YES (in case of error) | in case an error occurred HTTP status should not be 200 this error information should be returned. In case any of the transmitted hashes was not processed correctly this information is mandatory! This information will be used for error message display in games frontends! |
| clientMessage | clientmessage | NO | defines a message box to be displayed inside the game client. Can also be sent when an error occurred. |
| hashesProcessed | array of json objects | YES | array of transaction hashes and the result of processing. This should also be returned in case an error occurred. Transaction hashes not in that list will be assumed to not processed and therefore be treated as an error. For details see here. The errorCode structure returned in the hashesProcessed will be logged! |
Structure of hashesProcessed
| attribute | type | allowed values | mandatory | notes |
| hash | hash | a transaction hash submitted in the call | YES | |
| errorCode | errorCode | the result of processing the transaction | NO | if not present processing of the call was successful |
Retry Logic / Error handling
If a HTTP return code 5xx or a network error is received upon a doTransaction call containing debits no retries are made and a VOID transaction will be sent and the gameround will be marked as “canceled”
If a HTTP return code of 4xx is received upon a doTransaction call containing debits no retries are made and the gameround will be marked as “canceled”.
If the payload of the doTransaction call does not contain a debit but a credit the call will be retried on all error conditions until the call succeeded or the gameround stranded manually!
Scenarios and samples
The following paragraph describes some scenarios and sample calls.
Scenario 1: single shot gamerounds
Single shot game rounds are games where the outcome of the game is determined after the initial bet of the player (e.g. a normal spin). In this case all transactions are transmitted in a single call having 2 (in case of no win) or 3 (in case of a win) transactions. The initial debit should be treated as the start of a new game round. In case there is an error on the debit (e.g. no balance available) a possible credit call has to be forfeited and the gameround will be marked as closed and failed.
In case there is an error on credit and the http error code is >= 500 the call will be retried for a couple of times. In case error persists or the http error code is greater than 400 and less than 500 a void transaction for the debit will be sent and the gameround will be marked as closed and failed.
Following are some sample calls showing 2 cases with and without a win. All calls assume the initial balance of the player is EUR 10. Fields that have to be included in the signature are highlighted in red.
Sample for a one shot game without a win
| Sample call for a one shot game without a win | Description |
| POST /doTransactions | submit a list of transaction |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "debit", "isFirstDebit": true, "currency": "EUR", "hash": "13536977-5cfa-430b-a019-18430d61b48f", "amount": 200, "timestamp": "2020-01-21T14:48:04Z", "reason": "spin" }, { "type": "end", "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12", "timestamp": "2020-01-21T14:48:04Z" } ], "transactionCount": 2 } | The player did a spin for 2 EUR and didn't win anything, as no start game round is present; the first debit indicates the start of a new round. The gameround is immediately closed. |
| debit / end example of fields to sign for transaction [ "13536977-5cfa-430b-a019-18430d61b48f", 200, "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12" ] | These fields have to be appended to the fields used for calculation of signature |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 800, "currency": "EUR" }], "hashesProcessed": [{ "hash": "13536977-5cfa-430b-a019-18430d61b48f" } ,{ "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12" }] } | Return a real money balance of EUR 8. |
Sample for a one shot game with a single win
| Sample call for a one shot game with a win | Description |
| POST /doTransactions | submit a list of transaction |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "debit", "isFirstDebit": true, "amount": 200, "currency": "EUR", "hash": "13536977-5cfa-430b-a019-18430d61b48f", "timestamp": "2020-01-21T14:48:04Z", "reason": "spin" }, { "type": "credit", "amount": 150, "currency": "EUR", "hash": "4fac9a5d-3662-4f85-88ad-8301681d4b61", "timestamp": "2020-01-21T14:48:04Z", "reason": "3 symbols in line 1" }, { "type": "end", "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12", "timestamp": "2020-01-21T14:48:04Z" } ], "transactionCount": 3 } | The player made a spin for 2 EUR and won EUR 1.50, as no start game round is present the first debit indicates the start of a new round. The gameround is immediately closed. |
| debit/credit/end example of fields to sign for transaction [ "13536977-5cfa-430b-a019-18430d61b48f", 200, "4fac9a5d-3662-4f85-88ad-8301681d4b61", 150, "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12" ] | This fields have to be appended to the fields used for calculation of signature |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 950, "currency": "EUR" }], "hashesProcessed": [{ "hash": "13536977-5cfa-430b-a019-18430d61b48f" } ,{ "hash": "4fac9a5d-3662-4f85-88ad-8301681d4b61" } ,{ "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12" }] } | Return a real money balance of EUR 9.50 |
Scenario 2: multiple transaction calls for a gameround
Multiple doTransactions calls are made when outcome of the game cannot be determined after the initial bet of the player (e.g. a bonus round is entered or in game free spins are awarded). In this case all transactions are transmitted in multiple calls having 1 or 2 transactions. The first call will always be an initial debit call, wins and additional bets will be transmitted in separate calls. At the end of the gameround an end action will be transmitted or appended to the last credit call. In case there is an error on the initial debit (e.g. no balance available) the gameround will be marked as closed and failed. No further calls to this game round should be accepted (except end action).
In case there is an error on credit and the http error code is >= 500 the call will be retried for a couple of times. In case error persists or the http error code is greater than 400 and less than 500 a void transaction for the debit will be sent and the gameround will be marked as closed and failed.
In case an error is received on submitting an additional bet (isFirstDebit is false) no further action should be taken as the game could continue with a smaller stake (in this case a new debit transaction will be sent).
In case a second initial bet is received for the same gamer round hash it should always be answered with an error as the gameround has already been started. No further action should be taken.
Following is an example of a multi transaction call flow. All calls assume the initial balance of the player is EUR 10. Fields that have to be included in the signature are highlighted in red.
Sample for a gameround with multiple calls (6 calls in this example)
| Sample call sequence for multiple calls within a gameround (in this case a basic game + a bonus round with an additional wager | Description |
| Sample payload | Description |
| Sample response (success) | Description |
| Step 1 POST /doTransactions | submit initial debit and start a new gameround |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "debit", "isFirstDebit": true, "amount": 200, "currency": "EUR", "hash": "13536977-5cfa-430b-a019-18430d61b48f", "timestamp": "2020-01-21T14:48:04Z", "reason": "spin" } ], "transactionCount": 1 } | user bets an initial 2 EUR |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 800, "currency": "EUR" }], "hashesProcessed": [{ "hash": "13536977-5cfa-430b-a019-18430d61b48f" }] } | Return a real money balance of EUR 8. |
| Step 2 POST /doTransactions | user won on the basic spin |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "credit", "amount": 150, "currency": "EUR", "hash": "4fac9a5d-3662-4f85-88ad-8301681d4b61", "timestamp": "2020-01-21T14:48:04Z", "reason": "3 symbols in line 1" }, ], "transactionCount": 1 } | user wins EUR 1.50 from basic spin |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 950, "currency": "EUR" }], "hashesProcessed": [{ "hash": "4fac9a5d-3662-4f85-88ad-8301681d4b61" }] } | Return a real money balance of EUR 9.50. |
| Step 3 POST /doTransactions | user places a continuation bet |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "debit", "isFirstDebit": false, "amount": 170, "currency": "EUR", "hash": "2f1e3eeb-4330-4d26-87d8-4a72b3fdc4d6", "timestamp": "2020-01-21T14:48:04Z", "reason": "get more scatters bet for bonus round" } ], "transactionCount": 1 } | user bets EUR 1.70 to get additional scatters in a bonus game |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 780, "currency": "EUR" }], "hashesProcessed": [{ "hash": "2f1e3eeb-4330-4d26-87d8-4a72b3fdc4d6" }] } | Return a real money balance of EUR 7.80. |
| Step 4 POST /doTransactions | user wins in a bonus game |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "credit", "amount": 950, "currency": "EUR", "hash": "02ab706a-749a-4851-894b-ba48bec74ec4", "timestamp": "2020-01-21T14:48:04Z", "reason": "win in bonus game" }, ], "transactionCount": 1 } | user wins EUR 9.50 in the bonus game |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 1730, "currency": "EUR" }], "hashesProcessed": [{ "hash": "02ab706a-749a-4851-894b-ba48bec74ec4" }] } | Return a real money balance of EUR 17.30. |
| Step 5 POST /doTransactions | the gameround is closed |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "end", "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12", "timestamp": "2020-01-21T14:48:04Z" } ], "transactionCount": 1 } | gameround is finished, no more debits and/or credits should be accepted |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 1730, "currency": "EUR" }], "hashesProcessed": [{ "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12" }] } | Return a real money balance of EUR 17.30. |
| Step 4a (replaces 4+5) POST /doTransactions | this is an alternative to steps 4 + 5 where the gameround is closed with the last credit |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameCode: "testgame", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "transactions": [ { "type": "credit", "amount": 950, "currency": "EUR", "hash": "02ab706a-749a-4851-894b-ba48bec74ec4", "timestamp": "2020-01-21T14:48:04Z", "reason": "win in bonus game" }, ], [ { "type": "end", "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12", "timestamp": "2020-01-21T14:48:04Z" } ], "transactionCount": 2 } | user wins EUR 9.50 in the bonus game, then the gameround is finished, no more debits and/or credits should be accepted |
| Sample response (success) | Description |
| { "balances": [{ "type": "real", "amount": 1730, "currency": "EUR" }], "hashesProcessed": [{ "hash": "02ab706a-749a-4851-894b-ba48bec74ec4" },{ "hash": "b92f866a-5fe9-4ac1-ae0d-9f403dfe1a12" }] } | Return a real money balance of EUR 17.30. |
logEvent (optional)
This call is used to inform the operator of any events that might happen. This can be turned on/off by logging in with your credential to the hizi.io backoffice. An event is always bound to a player and optional to a gameround. Events might include big wins or other events that might happen during a game (free spins won, bonus level entered). Please refer to Appendix A for details on events
It is the operator responsibility to store this data. It is recommended to expose these events to the operator helpdesk as it might contain information about big wins or big stakes.
| POST /logEvent | submit a event | ||
| request Parameters (JSON payload) | |||
| attribute | type | mandatory | notes |
| playerId | string | YES | ID that identifies the player at the operators site |
| gameRound | hash | NO | gameround that the event is bound to |
| eventType | string | YES | a string describing the event |
| eventData | jsondata | NO | a json structure describing the event, please refer to Appendix A, which describes the possible values. |
| reason | string | NO | optional reason of this call |
| fields to sign (order is important) | |||
| secret + X-H-AUTH-ID + X-H-TIMESTAMP + playerId + (gameround if present in payload) | |||
| mandatory request header fields | |||
| X-H-AUTH-ID, X-H-AUTH-SIG, X-H-TIMESTAMP | |||
| returned attributes | |||
| attribute | type | mandatory | notes |
| errorCode | errorCode | NO | in case an error occurred HTTP status should not be 200 and additional error information can be returned |
Sample call to submit an event
Fields that have to be included in the signature are marked in red.
| Sample call to report a bonus win | Description |
| POST /logEvent | report a bonus win |
| Sample payload | Description |
| { "playerId": "sampleplayer", "gameRound": "04d4e7fc-092b-459e-bd32-c41343b4af2a", "eventType": "BONUSROUND", "eventData": { "credit": { "amount": 950, "currency": "EUR" }, "freespins": 10 }, "reason": "Player got 10 freespins" } | the player was awarded 10 in game free spins and has won EUR 9.50 |
| Sample response (success) | Description |
| { } | empty response |
doGameRoundReport (optional)
This call sends game round details only after the round has been closed. The payload includes the most important details of a game round, which can be used for reporting and historical purposes.
The operator must request that this endpoint be enabled; otherwise, requests will not be sent out.
| POST /doGameRoundReport | submit game round detail (for closed game round) | ||
| request Parameters (JSON payload) | |||
| attribute | type | mandatory | notes |
| gameRoundDetail | jsondata | YES | Game round payload |
| fields to sign (order is important) | |||
| secret + X-H-AUTH-ID + X-H-TIMESTAMP | |||
| mandatory request header fields | |||
| X-H-AUTH-ID, X-H-AUTH-SIG, X-H-TIMESTAMP | |||
| returned attributes | |||
| attribute | type | mandatory | notes |
| errorCode | errorCode | NO | in case an error occurred HTTP status should not be 200 and additional error information can be returned |
Sample call to submit a game round
Fields that have to be included in the signature are marked in red.
| Sample call to report a bonus win | Description |
| POST /doGameRoundReport | Send a game round’s payload |
| Sample payload | Description |
| { "gameRoundDetail": { "hash": "789b5513cb1a499dba181c6091c57d36", "mode": "REAL", "game": "bg-olympus-gold-96", "operator": "internal_testoperator", "status": "closed", "player": "acfbf7980c4d4add8688c944c9c2a22a", "language": "EN", "currency": "EUR", "environment": "gmzp", "timestamp": "2025-07-08T13:22:01.874+00:00", "baseStake": 10, "totalBetAmount": 10, "totalPayedAmount": 10, "totalWinAmount": 15, "dataStored": {}, "ticketUsed": false, "balanceAfter": 9075, "transactions": [ { "hash": "789b5513cb1a499dba181c6091c57d36", "type": "debit", "amount": 10, "payed": 10, "isFirstDebit": true, "currency": "EUR", "timestamp": "2025-07-08T13:21:44.599Z", "balanceAfter": 9060 }, { "hash": "3ef71295e3924915aec018ee32d10e17", "type": "credit", "amount": 15, "payed": 15, "currency": "EUR", "timestamp": "2025-07-08T13:22:01.555Z", "balanceAfter": 9075 }, { "hash": "637310141d1c4fdf8dc8579e0b8dec21", "type": "end", "currency": "EUR", "timestamp": "2025-07-08T13:22:01.855Z", "balanceAfter": 9075 } ] } } | Game round payload |
| Sample response (success) | Description |
| { } | empty response |
doGameRoundResult (optional)
This call sends the gameround result only after the round has been closed. The payload includes a HTML representation of a game result. The operator must request that this endpoint be enabled; otherwise, requests will not be sent out.
| POST /doGameRoundResult | submit game round result (for closed game round) | ||
| request Parameters (JSON payload) | |||
| attribute | type | mandatory | notes |
| gameCode | string | YES | Game code |
| msg | string | YES | BASE64 encoded HTML which can be used to display the game round. Buffer.from(body.msg,'base64').toString('utf-8'); |
| gameRound | hash | YES | Game round Id |
| playerId | string | YES | Player id |
| fields to sign (order is important) | |||
| secret + X-H-AUTH-ID + X-H-TIMESTAMP + gameRound + gameCode + playerId + msg | |||
| mandatory request header fields | |||
| X-H-AUTH-ID, X-H-AUTH-SIG, X-H-TIMESTAMP | |||
| returned attributes | |||
| attribute | type | mandatory | notes |
| errorCode | errorCode | NO | in case an error occurred HTTP status should not be 200 and additional error information can be returned |
Sample call to submit a game round result
Fields that have to be included in the signature are marked in red.
| Sample call to report a bonus win | Description |
| POST /doGameRoundResult | Send a game round’s HTML result |
| Sample payload | Description |
| { "gameRound": "789b5513cb1a499dba181c6091c57d36", "playerId": "acfbf7980c4d4add8688c944c9c2a22a", "gameCode": "bg-olympus-gold-96", "msg": "<html>...</html>" } | Game round payload |
| Sample response (success) | Description |
| { } | empty response |
reportAnimationEnd (optional)
This call is sent to the operator once the animation of the current gameround is finished and the spin / play button is active again and the player can start a new game. The call should never fail and always report HTTP 200 (success) back.
Usecase:
Gamerounds can be single Transaction and the gameround will be closed immediately in one doTransactions call client animations can still happen (so from a players point of view the game is still running). For certain legal frameworks where game start / end events are sent to a safe server to the regulator this call can be used to report correct game start / end events. This is mostly useful for German regulations.
The operator must request that this endpoint be enabled; otherwise, requests will not be sent out.
| POST /reportAnimationEnd | submit game round detail (for closed game round) | ||
| request Parameters (JSON payload) | |||
| attribute | type | mandatory | notes |
| gameRound | hash | YES | Game round to be reported as finished |
| fields to sign (order is important) | |||
| secret + X-H-AUTH-ID + X-H-TIMESTAMP + gameRound | |||
| mandatory request header fields | |||
| X-H-AUTH-ID, X-H-AUTH-SIG, X-H-TIMESTAMP | |||
| returned attributes | |||
| attribute | type | mandatory | notes |
| errorCode | errorCode | NO | in case an error occurred HTTP status should not be 200 and additional error information can be returned |
Sample call to submit a game round
Fields that have to be included in the signature are marked in red.
| Sample call to report a bonus win | Description |
| POST /gameRound | Gameround is finished (animation stopped) |
| Sample payload | Description |
| { "gameRound": "8a73676f4e5c4b4d8507b526f48b4f4d" } | Game round payload |
| Sample response (success) | Description |
| { } | empty response |
ping
This call is used to test the availability of the operator's service. It can be called any time and should return an HTTP error code 200 to confirm operation. Additional performance data might be returned which can be used for extended monitoring.
In case of getting repeated errors on this call you will be notified via the hizi.io Backoffice.
| GET /ping | call operator to confirm operation | ||
| request Parameters (URI parameters) | |||
| attribute | type | mandatory | notes |
| NONE | |||
| fields to sign (order is important) | |||
| secret + X-H-AUTH-ID + X-H-TIMESTAMP | |||
| mandatory request header fields | |||
| X-H-AUTH-ID, X-H-AUTH-SIG, X-H-TIMESTAMP | |||
| returned attributes | |||
| attribute | type | mandatory | notes |
| performanceData | jsondata | NO | additional data that could be used for monitoring |
| errorCode | errorCode | NO | in case an error occurred HTTP status should not be 200 and an additional error information can be returned |
Sample call to test availability of operator service
| Sample call, fields that have to be included in the signature are highlighted in red | Description |
| GET /ping | get operational status |
| Sample response (success) | Description |
| { "performanceData": { "status": "operational" } } | got a success and return an optional status |