Unibo
Game provider/Aggregator Integration

Metadata

Overview

Unibo requires a complete list of players and games from your platform. This data represents the current state of your player base and game catalogue and is used internally by Unibo to enable campaign setup, targeting, and processing.

The Metadata integration ensures that Unibo has an up-to-date view of players and games as changes occur on the platform.

Data Privacy & Personal Data

Unibo does not require or store any personally identifiable player information (PII), such as names, email addresses, phone numbers, or physical addresses.

Players are referenced exclusively by a platform-generated player ID, and never by personal identifiers such as name or email. Only a minimal set of technical and account-related attributes is required (e.g., player ID, currency, registration date, and status).

Integration Methods

Unibo supports two complementary methods for providing player and game data. The exact setup is aligned during integration.

1) Event Stream

Player and game data may be sent via the Event Stream as part of normal event reporting. This typically includes:

  • An initial seed when Unibo is enabled, containing all existing players and games

  • Incremental updates to reflect changes such as new players, new games, or updates to relevant attributes

2) Dedicated API

Alternatively, or in addition, the platform may expose dedicated endpoints that allow Unibo to fetch player and game data.

This typically includes:

  • Endpoints to fetch all players and games, used for initial synchronization and periodic reconciliation

  • Endpoints to fetch players or games created or updated within a recent time window (e.g. last 5 minutes), allowing Unibo to poll regularly (e.g. every 10–60 seconds)

Data Model

The fields below represent the minimum required core attributes used by Unibo.

Platforms may optionally provide additional non-personal player attributes beyond the core fields. The number, structure, and naming of such attributes are platform-defined and aligned during integration.

Players

Field (* = mandatory)

Data Type

Additional Info

id*

String

Unique player identifier

currency*

String

ISO-4217 currency codes

registrationDate*

String

ISO-8601, UTC

status*

String

"ACTIVE", "BLOCKED", "FROZEN", or "INACTIVE"

country

String

ISO 3166-1 alpha-2 country code

operator*

String

Operator name

Games

Field (* = mandatory)

Data Type

Additional Info

gameId*

String

Example: "4399" or "btg/bonanza"

gameName*

String

Example: "Bonanza"

gameProvider*

String

Example: "Big Time Gaming"

gameCategory*

String

Example: "table-games"

gameSubCategory

String

Example: "blackjack"

themes

Array

Example: Fruits, Ancient Egypt, Halloween, Christmas

features

Array

Example: Megaways, BonusBuy, Free Spins, Bonus Game, Sticky Wilds

deviceType

String

Example: "desktop", "mobile", "all".

hasFreeSpins

Choice (string)

Example: yes, no . Used to filter games during free spin reward creation.

The data model above may be adjusted depending on platform structure and use case, and is finalized during the integration kickoff.

Was this helpful?