Introduction

Gamity - Technical Integration Guide

Introduction

Welcome to Gamity, Codemodity’s gamification and tournament platform that aims to improve player engagement and retention. This document describes the technical details of how operators and providers can integrate with Gamity.

We aimed to make the integration as simple and quick as possible, using the fewest integration points needed, while still achieving great functionality.

This documentation is available online at https://developer.gamity.io, as well as in a PDF format generated from the online version. If you are reading the PDF, consider visiting the online documentation, which may be more up to date and provides a better navigation experience.

Definition of terms

  • Integration: represents the technical connection between Gamity and an external system, such as a casino platform (PAM), game aggregator, or game provider. An integration determines the available operators, brands, games, and gameplay information. Each integration is linked to an API key, which is used to authenticate all incoming API calls (e.g., game transactions).

  • Account: represents a group of users who have the right to manage a set of operators and brands for creating tournaments and other gamification events.

  • Brand: refers to a brand of an iGaming operator that has its own player base (a combination of brand and player ID uniquely identifies a player) and site design, which can serve as the basis for theming Gamity’s player-facing UI widget. For example, the gaming operator Gamesys has multiple brands, such as Jackpotjoy, Virgin Games, Botemania, and Vera&John, each with its own registered players. A tournament is associated with one or more brands, meaning that players from a specific brand (or multiple networked brands) compete against each other. The Brand ID (sometimes referred to as BrandRef) uniquely identifies a brand and must be included in the parameters for both UI widget launches and game transactions to correctly associate a tournament and its players. The format of the Brand ID is flexible and can be determined in collaboration with the client. It is recommended to use a natural identifier, such as “VeraJohn” or “Gamesys:VeraJohn”, for easier reference. However, if a surrogate ID from the client’s system (e.g., “1000188”) is more convenient to include in the required parameters for the UI widget and game transactions, that can be used instead. Brand identifiers must be unique across all brands within an Integration, regardless of the operator.

  • Game: tournaments are usually restricted to specific games. The Game ID must be passed to the UI widget as a parameter to display the appropriate tournament to the player, and the same game ID need to be included in the game transactions sent between the servers.

  • Tournament: allows players to prove themselves against each other and win prizes. The player base participating in a tournament is determined by which Brands and Games the tournament is set up for. Only players on select brands, playing with select games participate and progress in the tournament.

Main components

  • Leaderboard widget (UI): The player-facing UI (HTML/JS) widget offers convenient progress tracking on both desktop and mobile devices. It has a compact version that provides quick access to important information such as current rank and score, and an expanded version with more detailed information such as the entire leaderboard, prize table, and terms and conditions. The widget is optimized for the best user experience, including support for both portrait and landscape modes on mobile devices. This widget should be placed on the operator’s site or provider’s games, ideally where the games are launched.
    Can be integrated as a a simple Vue or React component, or a plain html script tag that references our external widget script, and some parameters for game and player identification.
    Read more

  • Game round/transaction API (server to server): for receiving and processing completed game rounds or individual transactions (i.e. bets and wins) to calculate players’ scores and rank them accordingly. Receiving complete game rounds is preferred over individual transactions, as it reduces data volume and eliminates the need to detect the end of a round. Gamity receives this data from the client’s backend. This can be an API on Gamity’s side where clients push data, or an API provided by the client that Gamity pulls data from. Apart from an HTTP API, we can also retrieve data via direct database connections, from Apache Kafka, or other sources. The integration method is to be discussed individually with the client’s tech team.
    Read more

  • Back-office site: provided by Gamity for the client’s team to set up tournaments and monitor their performance via reports.

  • Payout API (server to server): an HTTP API endpoint implemented by the client, where Gamity can send credits for the tournament winners (players). Effectively an endoint that allow Gamity to credit players’ wallets with the tournament winnings.
    Read more

  • [OPTIONAL] Debit API (server-to-server): An HTTP API endpoint implemented by the client, where Gamity can debit players for certain gamification features that require a fee for participation (e.g., tournament buy-in).
    Read more

  • [OPTIONAL] Tournament lobby (UI): A player-facing page that shows all ongoing tournaments. It can be included as a sub page of the operator’s site, under a ‘Promotions’ or ‘Tournaments’ menu item.

These components are described in more details in the subsequent sections of this document.

Overview