Home › Guides › Game metadata and lobby navigation
Operator guide · updated 24 September 2026
Game metadata and lobby navigation: what providers supply and how to use it
The question, as operators put it: “How do slot providers typically supply game metadata (themes, volatility, RTP variants, max win) and how can I use it to improve lobby navigation?” Here is the direct answer, followed by what our API actually returns and how to fill the gaps.
Short answer. Studios supply metadata mainly through game sheets and certification documents, with only a thin subset in their APIs, and every studio uses its own format. Aggregators normalise a few fields reliably — category, studio, images — and rarely carry volatility or max win consistently. The practical lobby is built on the normalised fields first, then on your own performance data, then on a small enrichment table for the games that carry most of the play. Our game list gives you the first layer — category, studio, images, launch identifiers — and studio game sheets supply the rest.
How studios supply metadata
There is no shared industry schema for game metadata. What exists is a set of habits that most studios follow, each in its own format.
- Game sheets. A spreadsheet or PDF per release, sent to distributors and operators before launch: theoretical RTP, volatility band, maximum win as a multiple of the stake, hit frequency, paylines or ways, bet range, features, themes and marketing copy. The richest source, and the least machine-friendly.
- Certification documents. Reports from the testing laboratory that certify each RTP version for a market. The authoritative source for “which RTP does this build pay”.
- Game-list APIs. Name, identifiers, category, images, device support, sometimes RTP. Thin, inconsistent between studios, and not always updated when the game sheet changes.
- Marketing assets. Tile images, banners, short descriptions. Useful for the lobby, not for filters.
RTP variants: the field that needs the most care
Many studios produce the same game at several return-to-player settings a few points apart, and the operator or the regulator chooses one. The reels, art and features are identical; only the pay table weighting differs. That is what “RTP variants” means.
For lobby and compliance purposes the consequence is simple: a single RTP number attached to a game name is not reliable unless you know which version your account receives in each market. If you display RTP — and some regulated markets require it to be available to players — take it from the configuration you actually run and the matching certificate, not from a headline figure.
What the SoftAggregator game list returns
Our getGameList response, as published in the API documentation, gives the fields below for every game. RTP, volatility, max win and themes generally come from the game sheets each studio publishes, and operators add them to their own catalogue for lobby navigation; the table shows where each piece of metadata comes from and how to use it.
Game metadata: where each field comes from
API fields as documented on 24 September 2026.
| Metadata | Where it comes from | Field or source | How to use it in the lobby |
|---|---|---|---|
| Normalised category | getGameList | game_type, 11 fixed values | Primary navigation: slots, live, crash, table… |
| Studio | getGameList and getProviderList | provider, provider_name, provider_logo | Studio filter, one-to-one match |
| Raw studio labels | getGameList | type, category | Kept for compatibility; navigation is built on game_type |
| Tile image | getGameList | image | Tiles and search results |
| Launch identifier | getGameList | id_hash | Key for your own enrichment table |
| Demo available | getGameList | play_for_fun_supported | Show or hide a demo button |
| Theoretical RTP and variants | Studio game sheet and certificate | Your catalogue, per configuration | Display where required; match the version you run |
| Volatility | Studio game sheet | Your enrichment table | Filter for key titles |
| Max win | Studio game sheet | Your enrichment table | “Big win” shelves |
| Themes and features | Studio game sheet, marketing assets | Your own tagging | Theme filters and collections |
| Observed return and GGR | Operator backend | Per game and per period | Sort by what players actually play |
The normalised category is your first navigation layer
Studios label their games inconsistently — our documentation notes around two dozen labels for a handful of real categories, and many crash games labelled as slots. We therefore add game_type, a normalised value from a fixed list: slots, live, crash, table, instant, bingo, keno, fishing, virtual, sportsbook and other. The list will not change without notice.
Build your top-level tabs from it. A crash tab that actually contains the crash games, and a live tab that contains every live table, does more for navigation than any number of theme filters. The casino game aggregator API page explains how the same list feeds every category, live tables included.
The studio filter, done properly
getProviderList returns each studio once, with a display name, a logo and the number of games, and its provider value matches the same field on every game — a straight one-to-one match for your filter. Studios that publish under several codes are merged into one entry, so players do not see the same studio twice. Logos are 400×160 PNG files served from our own CDN, cached for a day, so an improved logo reaches your lobby without a change on your side.
Use your own data before anyone else’s
The most useful sort order in a lobby is not volatility; it is what your players actually open and keep playing. Your operator backend shows bets, wins, observed return and GGR per game and per period, and your own launch log shows which tiles are clicked.
Three shelves built from that data usually outperform theme-based navigation: “popular here” by launches over the last seven days, “new” by first appearance in your game list, and “back to” for the player’s own recent games. None of them need metadata from anyone.
Enrich the games that matter, not all of them
Once the basics are in place, add a small enrichment table on your side, keyed by id_hash, for the titles that carry most of the play. Fill it from the studios’ game sheets: volatility band, max win multiple, a handful of themes, key features such as bonus buy or hold-and-win.
- Take your top titles by turnover over the last month.
- Record volatility, max win and themes from each studio’s game sheet, with the date you checked.
- Expose two or three filters built from that table — volatility and a short theme list are enough.
- Refresh monthly; add a game when it enters the top of your list.
- Never show a field you have not verified; leave it blank instead.
A table like this stays small, stays accurate, and survives a change of supplier, because it is keyed to your own catalogue data. For live tables the same approach works with different fields — limits, format, speed; see the live baccarat, live roulette and live blackjack pages for the attributes worth tagging.
Search, currencies and markets
Search is navigation too. Index the game name, the studio display name and your own tags; most players search by a name they half remember or by studio.
Filter the lobby by what can actually open. The catalogue and currencies evolve continuously; the up-to-date list is always in the API. Currency support varies by studio, and a game that cannot launch in the player’s currency should not be on the shelf; getCurrencies tells you what your account serves. For real-money launches, send the player’s country so studio restrictions are applied cleanly. If demo tiles differ by market, the guide to demo mode per jurisdiction covers that, and the broader casino aggregator API overview covers currencies and catalogue control in one place.
Game metadata and lobby navigation — FAQ
How do slot providers typically supply game metadata?
In three ways, often all at once: a game sheet (a spreadsheet or PDF per release with RTP, volatility, max win, paylines, features and themes), certification documents from the testing laboratory that confirm each RTP version, and fields in the studio’s own game-list API, which are usually thinner. The formats differ from studio to studio, and there is no industry-wide schema.
What does the SoftAggregator game list give me to build a lobby?
For every game, getGameList returns the name, a normalised category (game_type), the studio key with its display name and logo, the raw studio labels, the launch identifier (id_hash), an image and a demo capability flag. RTP, volatility, max win and themes generally come from the game sheets each studio publishes; operators add them to their own catalogue, keyed by id_hash, to drive lobby filters.
What is an RTP variant?
Many studios build the same game at several return-to-player settings — for example a few points apart — and let the operator or the market choose one. The game looks identical; only the maths differs. The version a player gets depends on configuration, which is why a published RTP number is only meaningful if you know which version your account receives.
How can I build lobby filters without volatility data from the API?
Start with what is reliable: category, studio and your own performance data. Then add an enrichment table keyed by id_hash for the titles that matter — volatility, themes, max win — sourced from studio game sheets. A few hundred well-tagged games cover most of the play in a typical lobby.
Should I show RTP to players?
Only if you can verify the version your players receive, and in some markets you are required to make it available. Showing a studio’s headline RTP when your configuration uses a lower version is misleading, and in regulated markets it can be a compliance problem.
Why should I use game_type instead of the type field?
Because type and category are passed through from each studio and are inconsistent: there are around two dozen labels for a handful of real categories, and many crash games arrive labelled as slots. game_type is our normalised value from a fixed list of eleven, which will not change without notice.
Sources and last update
This guide describes common industry practice for game metadata. Every statement about the fields our API returns is taken from our public documentation.
- SoftAggregator API documentation — getGameList (game_type list, raw labels, flags), getProviderList (merged studios, logos), getCurrencies. Checked 24 September 2026.
- SoftAggregator operator backend reporting as described on our public pages (per-game bets, wins, observed return, GGR). Checked 24 September 2026.
Last reviewed: 24 September 2026. If a field changes, this page will be updated with it.
Build your lobby on a clean game list
Read the game list and provider list in our docs, then request operator access to pull the real catalogue.
Request operator access