Upload your game catalog

CSV with columns gameId, name, provider, publishedRtp, volatility. Common names like game_code, studio, rtp, variance also work. Up to 100,000 games per file; re-uploading updates existing games.

Is every game paying what it says?

For each game with a published RTP, SlotClarity compares the payout across all your players with the published figure and tests whether the gap is bigger than chance allows. A strong deviation usually means the wrong RTP version is deployed, a jackpot contribution is misconfigured, or round data is incomplete. Games marked consistent show players a “Payout verified” badge.

Uses the per-spin standard deviation from your catalog's stdDev column (PAR sheet) when provided, otherwise an estimate from volatility. “Watch” = |z| ≥ 3, “Deviation” = |z| ≥ 4.5 (about a 1 in 150,000 chance for a correctly configured game).

Players who may need a check-in

Based on the last 30 days of play: chasing losses, escalating stakes, accelerating losses, long or late-night sessions, very frequent play and large single-session losses. These are prompts for your safer-gambling team to review, not a diagnosis, and players never see them. They are for human review only: do not use them to restrict accounts automatically (GDPR art. 22). Third-party scores sent to PUT /v1/players/:ref/risk appear in Player lookup.

Activity review prompts (UKGC RTS 12)

Accounts with play in the last 12 months must be prompted at least every 6 months to review their account activity; players can ask for more frequent reminders in their panel. This list shows who is due now. Send your prompt (email, inbox or pop-up) with a link to the account page opened on the review tab: <slot-clarity tab="review"> or /embed#tab=review. Completed reviews appear in the impact report.

Safer-gambling impact

Evidence for your compliance file: how many players look at their own results, set a play plan, see reality checks and ask for breaks. Counts only; no player is identified.

Players viewing their stats per day

Look up a player

For support and safer-gambling staff: last 30 days, recent sessions, limits, play plan, indicators and break requests. Every lookup is recorded in the audit log.

1 · Send rounds

From your backend, as rounds settle. Retries are safe: duplicate round IDs are ignored.

Already have a round webhook? Point it at /v1/webhooks/rounds: common field names and decimal amounts are mapped automatically (add ?amounts=minor if you send cents).

2 · Get a player token (backend)

3a · Embed as a component

3b · Or embed as an iframe (no build step)

Team

Give each person their own sign-in with a password and an authenticator-app code, instead of sharing an API key. admin: everything · analyst: reports, lookups and the safer-gambling views, read-only. Every sign-in is in the audit log.

API keys

Give each system its own key with only the access it needs. ingest: send rounds, catalog and limits · tokens: mint player tokens · read: reports and player lookups · admin: configuration, keys, erasure, audit.

Rotate API key

Creates a new key and disables the current one immediately. Update your backend right after.

Webhooks

SlotClarity POSTs player.break_requested immediately when a player asks for a break, and checks every 5 minutes for rg.markers (players with new safer-gambling indicators), integrity.deviation (games failing the RTP test) and, if enabled, session.ended. Each request is signed: x-slotclarity-signature: t=<unix>,v1=HMAC_SHA256(secret, "t.body").

SaveSend test event

Rebuild statistics

Recomputes every player's stats from stored rounds. Only needed after a support request.