How We Capture Slot Data — Methodology

What this page is

This is a record of how every number on this site is produced. Each RTP figure, symbol payout, volatility rating and screenshot in the catalogue comes from one place: our own automated pipeline, run against live provider demos. Nothing here is copied from review sites, affiliate pages, press releases or competitor databases.

The principle is simple. If we publish a value, we read it ourselves from the game or its paytable. If we can't read it, we don't print it. We show when we captured each record so you can judge its freshness for yourself, and we are explicit about what our method does not cover. That honesty is the point of this page — the limitations matter as much as the capabilities.

More about who we are and why we built this is on the About page.

The pipeline — five automated stages

Every slot passes through the same five stages. There is no manual data-entry step where a person types in RTP from a third-party source.

1. Demo discovery. We locate the official provider demo — studio press rooms, demo pages, or direct game embeds. We deliberately do not pull from aggregators, casino lobbies or review sites, because those add a layer we can't verify.
2. Live load and screenshots. Each game is loaded in a headless browser and played through its states. We capture a set of screenshots — on the order of 20 per game on average — covering the intro/logo, base game, paytable, rules screens, bonus-buy menu, free spins, win screens and settings, across both desktop and mobile layouts.
3. Symbol extraction. For each symbol we read its role (wild, scatter, high-pay, low-pay, bonus), its dominant hex colour, and its payout values straight from the in-game paytable. Across the catalogue this works out to roughly 14 symbols per slot.
4. Structured metadata. We parse 45+ structured fields per slot: RTP (the default plus up to 30 published variants), volatility on a 6-point scale, max win (as a multiple of stake), reels × rows, bet mechanic (lines / ways / cluster / Megaways), bonus-buy availability and cost, jackpot type and tiers, ante-bet cost, payline direction, themes, features (around 23 base mechanics tracked), studio, series and licensed IP.
5. Freshness re-capture. Slots are re-checked on a rolling schedule, and every record carries a captured_at timestamp marking when its data was last read.

What each field means and where it comes from

Each field maps to something we read directly from the paytable or the demo's own UI — not inferred, not estimated. A captured record looks like this:

{
  "name": "Gates of Olympus",
  "slug": "gates-of-olympus",
  "rtp_default": 96.50,
  "volatility": "high",
  "max_win": 5000,
  "reels": 6,
  "rows": 5,
  "bet_mechanic": "cluster",
  "has_bonus_buy": "yes",
  "bonus_buy_cost": 100,
  "screenshot_count": 34,
  "symbol_count": 14,
  "captured_at": "2026-06-21T11:34:00Z"
}

Reading that example field by field:

• rtp_default is the return-to-player percentage as printed in the game's information/rules screen. Where a provider ships multiple configurable variants, we store those too — but the default is the one shown by the demo we loaded.
• volatility is the studio's own published rating, mapped to a 6-point scale.
• max_win is the maximum win cap, expressed as a multiple of stake, as stated in-game.
• reels, rows, bet_mechanic describe the grid and how wins are formed — read from the rules.
• has_bonus_buy / bonus_buy_cost come from the feature-buy menu inside the demo, when one exists.
• screenshot_count / symbol_count are counts from our own capture of that game.
• captured_at is the UTC timestamp of the capture run that produced this record.

Our honesty rules

Two rules govern every record, without exception.

1. No field is inferred. If a value cannot be read from the paytable or the demo, it is shown as —. We never guess, never back-fill from another site, and never carry a "typical for this studio" placeholder. A blank means we could not read it — nothing more, nothing less.

2. Every record is timestamped, openly. Each slot displays its captured_at date. We don't hide it behind a "last updated" label that quietly refreshes on page load. The timestamp reflects the actual capture run, so you can weigh how current the data is.

What we don't do — limitations

We would rather you trust this site for what it is than over-trust it for what it isn't. Three limits are worth stating plainly.

• No casino cross-checking. Our single source is the official provider demo. We do not verify values against live casino lobbies, and we do not reconcile operator-specific RTP variants. A real-money operator may run a different RTP configuration than the demo advertises; we cannot see that, and we don't claim to.
• Demo-only coverage. A slot is fully shown to the public only when it has a usable, loadable public demo we can capture and display. Many documented games don't currently meet that bar, so only a fraction of the catalogue carries a live demo we can show. The catalogue is 600+ slots and growing, but demo-backed coverage is a subset of that.
• Re-capture lag. There is always a window between a provider updating a game and our next scheduled re-capture. During that window a record can be stale. We don't pretend otherwise — that's exactly why captured_at is shown on every record, so the judgment about freshness stays with you.

Corrections

If you spot a value that looks wrong, tell us — we'd genuinely like to know. Email [email protected] with the slot name and the field in question, and we'll re-capture and review. Every correction helps tighten the pipeline.

You can browse everything described here in the catalogue.