The recommended beginner path for configuring the shared singleton, saving one game, and branching into named slots.
JavaScript Simple Game Saves
Use the canonical simple game-save flow, then apply JavaScript-specific notes.
The recommended beginner path now lives at /simple-game-saves. This page keeps JavaScript SDK context for browser storage, local-first saves, sync timing, and when to drop to the advanced runtime client.
Canonical Flow
Start with the Simple Game Saves guide.
Use PersistlyGameSaves.configure, saveData, loadData, and forceSyncData first for one-save games. Move to saveSlot/loadSlot when your game has multiple saves.
Boot flow, cross-browser restore, accountData, lifecycle sync, and safe cleanup.
Autosave
Keep gameplay local-first, then sync at safe moments.
The JavaScript facade lets the game update local progress immediately without sending every state change to Persistly.
Use saveData whenever one-save gameplay state changes; the SDK writes the draft locally first.
Use saveSlot(slotId) instead when the game has manual saves, campaigns, or multiple slots.
Use forceSyncData or forceSync(slotId) at safe moments such as checkpoint, pause, manual save, level complete, or app background.
Keep the sync cadence predictable so runtime request limits are easy to reason about.
JavaScript Behavior
These runtime guarantees are what the SDK preserves in browser games.
The JavaScript SDK supports browser games, JavaScript clients, and wrapper apps.
PersistlyGameSaves is the default facade for normal game integrations.
saveData and loadData are the easiest one-save path; they use the default autosave slot under the hood.
Browser integrations use Persistly's built-in localStorage adapter by default; storageHelper is available only when a game needs a custom local storage implementation.
inspectData, acceptCloudData, overwriteCloudData, and keepLocalDataForLater keep one-save conflict recovery free of slot-key parameters.
saveSlot writes named-slot gameplay data immediately; loadSlot reads local data so the game can boot quickly, even offline.
The first forceSyncData, forceSync, syncDueSlots, or syncDue call creates the remote Persistly account and matching slot if needed.
One-save games can stay on saveData/loadData, while named slots such as slot-1, warrior, or mage let games grow into manual saves, campaigns, or slots.
Anonymous browser saves recover on the same browser storage automatically; another device can attach with a short-lived transfer code while the original session still exists.
AccountData is shared across slots and can hold account-wide gameplay data such as bundles, settings, shared inventory, or validated currency balances.
Raw account methods exist for lower-level direct integrations, but the SDK facade is the recommended path.
The facade writes local drafts immediately. Your game calls forceSyncData, forceSync, syncDueSlots, or syncDue from safe lifecycle moments; runtime policy controls due-sync cadence.
Conflict responses preserve local and cloud branches so the game can decide how to recover.
The SDK validates payload-size limits before requests leave the client.
Advanced Runtime
Use PersistlyClient only when you intentionally need lower-level control.
The JavaScript package also exposes account/session primitives for custom SDKs and wrappers. Most shipped games should keep PersistlyClient out of beginner game code and use the facade first.
accountId, accountSessionToken, accountData, slot references, and premium currency boundaries.
Shared account state for bundles, settings, shared inventory, and validated currency balances.
Use exported statuses and canonical server versions when remote sync reports a conflict.