Unibo
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).

Additional non-personal player attributes may be shared at the platform’s discretion. Providing richer player metadata enables more advanced campaign configuration and segmentation, but is entirely optional and controlled by the platform.

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

Username / alias

String

Optional player display name or alias used for UI elements such as leaderboards

Platforms may optionally provide additional non-personal player attributes beyond the core fields above. These attributes are platform-defined and may represent concepts such as tags, segments, player groups, levels, VIP scores, or other custom classifications.

The structure, naming, and number of such attributes are fully controlled by the platform and agreed upon during integration.

Games

Field

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.

Platforms may optionally provide additional game attributes beyond the core and capability fields above.

These attributes are platform-defined and may represent concepts such as RTP, volatility, or other custom classifications.

Additional game attributes can be used for filtering and segmentation during campaign creation. The structure, naming, and number of such attributes are fully controlled by the platform and agreed upon during integration.

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

Was this helpful?