Catalog requirements

Every game you distribute is one catalog entry, and that entry is your storefront. Operators browse GET /v1/games, filter by type, volatility, RTP, features, and currency, and decide what to enable from what the metadata tells them. A thin entry does not fail integration; it fails quietly later, as a game nobody launches. This page is the specification of what the entry carries.

What operators see

The operator-facing game shape is explicit and curated; these are the fields your metadata feeds:

Field	What it carries
name	Display name of the game
provider_game_id	Your own identifier for the game, unchanged
brand, category	Studio brand and catalog grouping
game_type	The game class operators filter by, for example slots or crash
rtp	Theoretical return to player; see the source requirement below
volatility	Declared volatility profile
features	Feature flags operators filter by, for example bonus buy or cascading reels
release_date	Release date, used for sorting new titles
thumbnail_url	Tile artwork; operators can add their own uploads on top
has_mobile, has_desktop, has_demo	Platform and demo availability flags
supported_currencies	The effective currency list; see below
blocked_countries	The enforced block-list; see below
certified_markets	Your declared certification allow-list; see below
min_bet, max_bet, default_bet, bet_limits_currency	Declared stake limits, quoted in the currency you name
max_win_multiplier	Maximum win as a multiple of the stake, currency-agnostic
bet_steps	Optional discrete stake ladder for one currency; feeds free-round stake discovery
free_rounds_support	Whether the game accepts free rounds, so operators can find issuable games

Beyond the operator-facing shape, we also take declared fields that serve the catalog itself: a game description, themes, hit rate, lines description, and certification and licence details. Hand over what you have; the connector work maps your format onto these fields, and after onboarding they stay editable.

RTP needs a named source

Every RTP figure arrives with its source named: your declaration, backed by the certificate or math sheet the number comes from. A silent default, the same 96.00 stamped across the catalog because nothing better was at hand, is not accepted. Where a game ships with configurable RTP variants, declare which configuration the listed figure describes.

The reason is not bureaucratic. Operators filter the catalog by rtp_min and rtp_max, show the figure in their lobbies, and answer to their regulators for what those lobbies claim. A wrong RTP is not a cosmetic defect; it is a compliance defect that surfaces on someone else’s licence.

Certified markets and blocked countries

Two market lists travel with a game, and they are different axes:

• certified_markets is your allow-list declaration. The regulated markets a game is certified or approved for, parsed from your declaration into a structured object: regulated jurisdictions, low-barrier markets, and an international flag. It is informational: operators use it to filter their storefront by what their licence permits. It is not a launch gate, and games with no declaration carry null.
• blocked_countries is the enforced block-list. Countries where the game must not launch, checked at launch time against the player country the operator declares. You declare a provider-level default, and any game can override it.

Declare both honestly. The allow-list sells your game to licensed operators; the block-list keeps it out of places it must not be.

Currencies and bet limits

Currencies. You declare the currencies your games support at the provider level, and any game can narrow that list for itself. The effective list, the game’s own if declared, otherwise your provider default, gates session launches and feeds the operators’ ?currency= catalog filter. A currency missing from the list means operators cannot launch your game in it.

Bet limits. min_bet, max_bet, and default_bet are stored exactly as you quote them, in the currency you name in bet_limits_currency. The platform never converts them: a static catalog figure converted at some day’s exchange rate would go stale the next day, so conversion for display is the operator’s decision, not catalog data. max_win_multiplier is a multiple of the stake and carries no currency at all.

Handing the catalog over

The format is agreed during onboarding: a structured export from your side, or a feed the connector pulls from your API. Either way, we load it, validate it against this specification, and come back with what is missing rather than guessing. After go-live the catalog stays alive: metadata corrections and new titles flow through the same channel, and declared fields remain editable without a new integration round.

Prepare RTP evidence, artwork and supported currencies before onboarding. These are handover requirements; nullable catalog metadata is not proof of certification or a universal API rejection. The team confirms any remaining gaps and actual enablement gates for your connector.