The public account identifier returned by Persistly. Games must persist it locally or in their own trusted backend.
Core Concepts
Use the same save model everywhere.
These concepts are the stable language of Persistly. Every SDK should preserve them instead of inventing new semantics.
Shared Language
These are the contract concepts game teams should learn first.
An account-scoped token returned once when an account is created. It authorizes loading the account and its named slots.
The stable developer-facing identifier for a named save slot, such as autosave, slot-1, warrior, or mage.
Optional non-secret developer reference. It is not authentication, account recovery, or public lookup.
Small account-level hints for display or future routing. Account-wide gameplay data belongs in account.data.accountData.
Small per-slot labels such as slot name, slot label, class, last played timestamp, and selection UI hints.
The full current gameplay JSON stored by Persistly for a slot.
The integer save revision the client last loaded. Sync uses it to detect conflicts; it is not a timestamp or SDK release version.
Mental Model
Persistly becomes easier to use when you keep the runtime flow explicit.
These steps matter more than memorizing every field name. If your game follows this flow, it stays aligned with the public runtime contract and future SDKs.
01
Create an account once and persist accountId plus accountSessionToken in the client.
02
Load the account through the session whenever the client resumes.
03
Load and sync named slots through the same account session.
04
Sync data plus slotInfo with baseVersion so Persistly can detect conflicts.
05
On conflict, compare the returned cloud branch with the local branch, preserve unsynced local edits separately if needed, then retry from the new version.
Important Boundary
playerRef is a stored reference, not a public runtime locator.
Public clients create accounts and store accountId plus accountSessionToken. They do not discover arbitrary accounts or saves by playerRef.
If a game needs external-account discovery before Persistly Auth exists, that lookup belongs in a trusted developer-managed backend or future Persistly trusted provider flow, not in shipped public clients.