Operator API Overview

Core APIs for Operator API

Operator API caters to all Operators whose goal is to integrate games into a third-party application through Niropa. For this, the following types of APIs are provided:

• Games API - allows Operators to request and receive the list of available games, which are provided and implemented by Niropa.
• Wallet API - an API for Seamless wallets, which Niropa triggers to update the user's balance. For this API, the Operator needs to provide corresponding endpoints based on the given API structures.
• TransferWallet API - an optional API for Transfer wallets, which is available by request. The API provides a way for the Operator to deposit money to the user's account, withdraw money from the user's account and get the user's balance. Availability of TransferWallet API is per request.
• Rewards API - an API for granting rewards, such as free spins, free rewards and prizes to one or multiple users. First-time user's bonuses are supported by most suppliers, however, in some cases a user must interact with the game before a free reward can be granted.
• Recommendations API - Games' recommendation to an Operator based on user's interactions (game plays) on Niropa platform.
• Transactions API - an API which provides a list of all user's gameplay transactions.
• On-Demand API - Specialized APIs available upon request. For accessing or setting up this functionality, please contact your technical contact on Niropa's side.

Getting started

To get started with setting up your integration with Niropa, you'll need to have the following:

• a public API key provided by Niropa;
• a private / public key pair that you generate yourself;
• an Operator ID provided by Niropa;
• a Game ID provided by Niropa.

To receive a public key provided by Niropa, you'll need to contact sales@niropa.com. They'll trigger the process from technical integrations side, the process should be as follows:

1. Receive a public key sent from Niropa.
2. To generate a private / public key pair on your side, run the following commands:
• Copy

  openssl genrsa -out private.pem 2048

• Copy

  openssl rsa -pubout -in private.pem -out public.pem

3. Send the public key to Niropa. Niropa uses this public key to verify the Games API requests.

Request signing logic for Operator API

The body of all requests will be signed with RSA-SHA256 using the respective private key and encoded to BASE64. The signature will be placed in the X-Niropa-Signature header.

• Games API
• All Games API requests have to be signed by Operator.
• Niropa verifies all Games API requests using the public key provided by the Operator.
• Wallet API
• All Wallet API requests have to be signed by Niropa.
• The Operator needs to verify all Wallet API requests using the public key provided by Niropa.
• All TransferWallet API requests must be signed by the Operator.

Example:

{"user":"3nYTOSjdlF6UTz9Ir","country":"XX","currency":"EUR","operator_id":1,"token":"cd6bd8560f3bb8f84325152101adeb45","platform":"GPL_DESKTOP","game_code":"clt_softwareid","lang":"en","lobby_url":"https://exampleplatform.io","ip":"::ffff:10.0.0.39"}

DYKK0KsSMayoyHcpFx32R57mZ8ey2r8U4RscT9LiWEFkd40V/f2n9JafsC+yuB8OSHz+wdCvyxvqacNiL8r3ZGEBdTL4lrcjdM5PWHQu8auYNp2mGE0tbX6/KGyk8nyQ3+h1HogIHj5hnMNYx0r+AhFT2tD/IT2b3Pq6oDPNL8rK0CbDCm8w7+gal1i0T1pDo61e2CTDTHpfm4ELEKcff2iiIRvgQ52nUCkuxQjCN/BGyEC1il0AVwlcb8CKU6Utg48UqvPLqu38qahI5X53zBMpLFIOtOYcFoepWmHvBxh0GDM4NIfQQ3Cm5sFyN3AsqzM7rqA0N9VZP0QPK8fA0g==

Request consistency

Wallet API requests have to be idempotent. All transactions contain a transaction_uuid field. The Operator has to ensure that requests with the same transaction_uuid are not processed twice, while the response has to be the same for all duplicate requests. The operator may ignore the idempotency requirement for the /user/balance call.

Gameplay overview

Once you meet the prerequisites, the process is as follows:

1. Obtain a game URL from Niropa.
2. Direct the customer to the URL provided by Niropa.
3. Respond to in-game events sent by Niropa and update the customer's balance (SEAMLESS WALLET ONLY)

The high level gameplay corresponds to the core communications flow between Supplier and Operator APIs.

Demo gameplay

1. Operator makes a Game API call to /game/url to obtain game launch URL. For DEMO mode, Operator has to pass "currency":"XXX". Parameters token, user may be omitted.
2. When the game URL is returned, the Operator uses it to direct the user to the game (for example, launch it in iframe or redirect the user to the URL).
3. In DEMO mode, no calls to Operator's API are made because providers handle the balance themselves. If user liked the game and wants to switch to REAL mode, Operator should proceed with the next steps.

Real gameplay

1. The Operator generates and stores a unique game session token.
2. The Operator makes a Game API call /game/url and passes the generated token along with the other request parameters. NB!: In case of SEAMLESS WALLET integration, Operator needs to be ready to respond to balance API calls even before getting the game URL back.
3. When the game URL is returned, the Operator uses it to direct the user to the game (for example, launch it in iframe or redirect the user to the URL).

Following steps are for SEAMLESS WALLET integration only. In case of TransferWallet integration, all game actions and balance updates will be handled on Niropa side.

4. When the game URL is loaded in the browser, Niropa server makes a Wallet API call /user/balance to the Operator's server.
5. The Operator verifies the token against the stored token and returns the user's balance. The user can then place a reward.
6. When the user attempts to place a reward, a Wallet API call /transaction/reward is triggered on the Operator's server.
7. The Operator verifies the token, ensures that the user has enough money for this reward, decreases the user's balance by the reward amount, and returns the updated user's balance.
8. If the user wins, the Wallet API triggers a call /transaction/win on the Operator's server.
9. The Operator verifies the token, increases the user's balance by the win amount, and returns the updated user's balance.
10. Behaviour in case of user's loss depends on game provider's internal logic. Possible options:
    • Nothing is sent
    • Sent win with amount 0