Saving User Data

Use userData to remember things about a player between plays: save data, settings, or how far they've progressed.

The Single-Slot Model#

Each Game can optionally declare one userData key in the Minit Games console. That key identifies a single per-player storage slot. Your game can read the slot on startup and write to it when the game ends.

Enabling userData in the Console#

1. Open your Game in console.minit.games.
2. Click Edit and check the Store User Data checkbox.
3. Enter a 1–64 character key, for example intro-seen or player-progress.
4. Save. The slot is now active.

To disable it, uncheck Store User Data and save. New plays stop reading or writing the slot. Existing data is not deleted; re-enabling with the same key surfaces it again.

You can change the key. Data stored under the old key becomes dormant: players will not see it via the new key. Reverting to the old key surfaces it again.

Mods: the userData setting is inherited from the base Game and cannot be changed in the mod editor. If the base Game has a key, all its mods share the same slot.

SDK API#

import { getUserData, reportResult } from '@minit-games/sdk'

const value = getUserData() // returns string | undefined

reportResult(score, { userData: 'done' })

Worked Example: First-Visit Flag#

import { getUserData, reportResult } from '@minit-games/sdk'

// On game start: check the "Store User Data" box in the console and set the key to "intro-seen"
const seen = getUserData()

if (seen === undefined) {
  showIntro()   // First time: slot not yet written
} else {
  skipIntro()   // Returning player: skip straight to the game
}

// When the game ends
function handleGameOver(score) {
  reportResult(score, { userData: 'done' })
}

Cross-Game Sharing#

Two Games by the same creator that declare the same key share a slot, by design, and across engines. Use it for cross-game continuity (e.g. a preference or a personal best shared by all of your Games); use a unique key per Game (towerDefense-highScore, not highScore) when each Game needs its own slot.

Limits#

An oversized value is not rejected. The play-report request still succeeds with a 200 response, but the userData value is silently discarded. See Limits & Constraints FAQ for the complete limit table and failure modes.

Keep values compact: store flags and small state, not full game replays. If you need to persist multiple values, encode them into a single string:

function handleGameOver(score, level, darkMode) {
  const value = JSON.stringify({ level, darkMode })
  reportResult(score, { userData: value })
}

function loadPlayerState() {
  const raw = getUserData()
  if (raw === undefined || raw === '') return { level: 1, darkMode: false }
  try {
    return JSON.parse(raw)
  } catch {
    return { level: 1, darkMode: false }
  }
}

Testing Locally#

http://localhost:5173/?userData=done

const value = JSON.stringify({ level: 3, darkMode: true })
const encoded = encodeURIComponent(value)
// Open: http://localhost:5173/?userData=<encoded>

Local only. URL params are used as a fallback when no host has injected real player data. In the Minit Games mobile app, the host always provides real data and URL params are ignored.

Data Persists Across Game Updates#

The slot is identified by the console key, not the ZIP, so player data survives re-uploading a new version.

Note: userData persists in the Minit Games mobile app AND on the web — the public play page and the Creator Console's Live Preview both store it in the parent page's own localStorage (keyed per creator + userData key), so it survives between sessions in the Console preview too, not just in the app.

Deeper Dives#