Ask each portal how it identifies its iframe (usually a query parameter on the game URL, sometimes the referrer) and check it once at load with a small switch, so one build can adjust ad calls or branding per portal without shipping separate builds.
At a glance
| Fact | Value | Source |
|---|---|---|
| CrazyGames iframe check | query param + absoluteURL.Contains | docs.crazygames.com |
| CrazyGames local dev override | ?useLocalSdk=true | docs.crazygames.com |
| Detecting host portals | check query parameters at load | developer.mozilla.org |
Read the query string on the URL your game is loaded with, and match it against the parameter each portal documents for its own iframe. For example, you can add a query parameter to your iframe URL when submitting and inspect the page URL in code. That is the pattern to copy for any other portal: agree on a parameter with the portal (or read one they already append), then branch your ad calls, SDK init, or branding based on it.
For deploying builds, Playgama MCP lets coding agents upload builds and publish sandboxes directly.
What should you check per portal?
- Ask the portal’s own docs for the exact parameter name and value – they differ per portal and can change, so don’t hardcode one you found once.
- Do the check once at startup, cache the result, and don’t re-read the URL on every ad call.
- Keep a local-dev override separate from portal detection to force local testing parameters independently.
- If no known parameter matches, treat it as your own site or an unlisted embed and use safe defaults rather than crashing.
Sources
- Introduction – CrazyGames Documentation
- Playgama for developers
- Playgama: MCP Server: Publish Games from Your AI Agent
Related questions
Should I detect the portal from the referrer instead of a query parameter?
You can, but referrers can be stripped or rewritten by proxies and some browsers. A documented query parameter agreed with the portal is more reliable.
Do I need a separate build for each portal?
No – one build can branch behaviour at runtime by reading the portal parameter, which is simpler than maintaining separate builds for each distribution target.
Last updated: 30 September 2026