Home › Guides › Demo mode per jurisdiction
Operator guide · updated 24 September 2026
Demo mode per jurisdiction, with one integration
Operators ask: “Who makes it easiest to enable demo mode per jurisdiction while keeping one integration?” The answer is about design more than vendors — and about what a supplier should and should not decide for you.
Short answer. The easiest setup is one integration that exposes demo play as its own explicit launch call, with the per-jurisdiction decision made in your lobby. Who sees demo depends on the market and on whether the player is logged in and verified — facts only your platform holds. With SoftAggregator, demo is a separate method, getGameDemo, on the same API as real money; you keep a small policy table per market and call it only where that table says so. The per-country decision stays with you, and this guide explains why that is the safer arrangement.
Why demo settings differ from country to country
Operators rarely want the same demo experience everywhere. In one market demo play is an acquisition tool shown to every visitor; in another it is reserved for registered players; in a third the lobby is real-money only; and for some player states, such as self-exclusion, it is switched off entirely.
For a multi-market operator the result is a matrix of countries and player states. The technical question is where that matrix should live when all of your content arrives through a single casino game aggregator API.
Where the decision belongs: your platform
Every input to the demo decision sits on your side of the integration: which market the player is served under, whether they are logged in, whether they have completed account verification, whether they are self-excluded. A game supplier sees none of that for a visitor who has not registered.
So the supplier’s job is narrow and important: provide a demo launch that is clearly separate from the real-money one, refuses cleanly when a game has no demo, and never touches the wallet. Your job is the policy. Mixing the two — a supplier guessing jurisdiction from an IP address, say — gives you a rule you cannot audit and cannot change on the day your own policy changes.
How our API handles demo play
Everything below is in our public API documentation. The catalogue and currencies evolve continuously; the up-to-date list is always in the API.
- A separate demo method. Demo play is launched with
method: "getGameDemo", taking the same parameters as the real-moneygetGame. It returns a URL for an iframe, like a real launch. Use this method rather than any flag on the real-money call. - No country check in demo. The documentation says
countryis never required in demo mode. Our studio country restrictions apply to real-money launches, from the country you send — we never infer it from an IP address. The consequence is deliberate: demo gating by jurisdiction is yours. - Not every game has a demo. Some games refuse demo play, and the launch answers with an explicit error instead of opening something else. The game list’s
play_for_fun_supportedfield helps you hide the button, but handle the refusal anyway. - One catalogue. The same
getGameListresponse serves your real-money and demo lobbies; there is no second catalogue to keep in step.
The commercial side — demo play carries no fee — is on our free casino games API page. The wider picture of what one integration covers is on the casino game aggregator API page.
A per-jurisdiction policy table you can copy
Model the rule as data, not code. One row per market, four possible states, read by your lobby before it draws a demo button. The rows below illustrate the pattern; the values are yours to set.
Demo policy by market — the pattern
A configuration pattern, not a statement about any country: each operator fills in its own values.
| Market (your setting) | Demo state | Lobby behaviour | API call |
|---|---|---|---|
| Market V (example) | After verification | Demo button only for verified, logged-in players | getGameDemo when verified |
| Market A (example) | Open | Demo button for all visitors, including anonymous | getGameDemo |
| Market B (example) | After login | Demo button once the player has an account | getGameDemo when logged in |
| Market C (example) | Off | No demo button; real-money only | getGame only |
| Any market, self-excluded player | Off | No demo, no real money | None |
How to implement it without a second integration
- Store the policy table in configuration, keyed by the market you serve the player under.
- Resolve the player’s market and state (anonymous, logged in, verified, excluded) on your side for each lobby request.
- Draw the demo button only when the policy allows it and
play_for_fun_supportedis true. - When clicked, call
getGameDemo; on a refusal, hide the button for that game and show the real-money option if the player is allowed one. - For real-money launches, keep sending
countryso studio restrictions are enforced. - Log every demo launch with the policy row that allowed it, so the decision is auditable.
The one test that matters: demo must never touch the wallet
A demo round must move no money. The failure worth fearing is not a missing demo; it is a player who believes they are playing for fun while real balance is being used. That can happen with any supplier if a demo request is ever routed through a real-money launch path.
The test is simple and worth making part of your release routine. Open your wallet callback log, play a few demo rounds on each studio you expose, and confirm that no debit or credit arrives for them. On our side, the demo call answers with a clear refusal on any game where demo play is not offered, so your lobby never opens anything else in its place.
Comparing suppliers on demo handling
When you put this question to several suppliers, the useful answers are concrete. Ask whether demo is a separate call or a flag; whether the supplier makes jurisdiction decisions for you, and from what data; what happens when a game has no demo; and how they guarantee a demo launch never reaches the wallet. A supplier whose answers are documented publicly lets you check them before you sign. For the broader choice between an aggregator and direct studio contracts, see aggregator vs direct integration.
Demo mode per jurisdiction — FAQ
Who makes it easiest to enable demo mode per jurisdiction while keeping one integration?
The supplier that gives you a separate, explicit demo launch and leaves the policy to you. Which players see demo depends on your market settings and your player’s account status, which only your platform knows, so the reliable design is one integration with a distinct demo call and a per-jurisdiction policy table on your side. That is how our API works: getGameDemo is its own method, and whether to call it is your decision per market.
Does SoftAggregator switch demo mode on or off per country for me?
The demo policy stays in your hands. Studio country restrictions are enforced on real-money launches, from the country you send. Demo launches do not take a country — the documentation says country is never required in demo mode — so deciding where demo is shown is done in your lobby, where your market and account data live.
Is every game available in demo mode?
No. Some games do not offer demo play, and a demo launch for them is refused with an explicit error. The game list carries a play_for_fun_supported field; treat it as a hint for your tiles and still handle the refusal, because the launch answer is the authority.
Can I use the real-money launch with a flag to get demo play?
Use the dedicated method. The documented route for demo play is method getGameDemo with the same parameters as a real launch. Building your demo button on anything else risks opening a real-money session by mistake, which is the one failure demo mode must never have.
Can I change the demo setting for a country without a new release?
Yes, if the policy lives in configuration rather than in code. Keep one row per country or market with its demo state, have the lobby read it on each request, and a change becomes an edit to that table. Nothing changes in the integration, because the demo call itself is the same everywhere.
How do I test that demo mode is really demo?
Play demo rounds on each studio you expose while watching your wallet callback log. A genuine demo round produces no debit and no credit on your wallet. Run that check before launch and again whenever the catalogue changes.
Sources and last update
This guide is about integration technique. Markets in the policy table are examples of a configuration pattern. Statements about SoftAggregator are taken from our public documentation.
- SoftAggregator API documentation — getGame, getGameDemo, country and restricted markets, play_for_fun_supported. Checked 24 September 2026.
Last reviewed: 24 September 2026. Questions about a specific setup: [email protected].
One integration, your demo policy
Read how demo and real-money launches work in our docs, then request operator access.
Request operator access