Skip to main content
Identity is resolved by the SusaPlay shell before your game starts. There is no login flow to build and no identity call to make — by the time Initialize() returns, the player is known.

Reading the current player

All four are null or false before Initialize() completes.

Guest sessions

Players can start without an account. The shell issues a guest session automatically.
Guests can use the wallet, saves, and analytics exactly like signed-in players.

Account merge

When a guest signs in, the platform links their existing progress to the new account. This is handled entirely by the shell — your game does not orchestrate it and does not need to migrate anything. Uid can change across sessions for a guest who later signs in. Never persist a uid in your own backend as a permanent key without also handling that transition.

Authentication tokens

The SDK attaches the player’s auth token to every platform request for you. There is no getIdToken in the Unity SDK, and a game should not need one. If your game calls your own backend, use SusaPlaySDK.Api — it signs those requests with the player’s identity so your server can verify who is calling:
Never trust a player id sent from the client. Verify it server-side on every request that grants anything.