Can players start as guests and create an account later?

Yes. Anonymous login creates a guest player, and upgrade-guest attaches email/password to that same player_id so documents, scores and balances stay on the same account.

Which credential is safe to ship in a game client?

The publishable API key is safe to ship and can bootstrap player authentication. Secret API keys and server tokens are trusted credentials and must stay out of player builds.

Does Crux support social OAuth for players?

Yes. Projects can configure Google, GitHub and Discord player OAuth from the Credentials dashboard using the exact callback URI Crux provides for each provider.

Can a Steam game authenticate players without trusting a client-supplied SteamID?

Yes. Configure the Steam App ID and publisher Web API key server-side in Crux. The game sends a GetAuthTicketForWebApi ticket; Crux verifies it with Valve and maps the verified SteamID64 to a stable Crux player.

Player auth · guest upgrade · token lifecycle

Let players start instantly without making account creation destroy their save later.

Start with a stable anonymous identity, issue player-scoped access and refresh tokens, then upgrade that same player without changing the player id. Add email/password, Google/GitHub/Discord OAuth, or server-verified Steam ticket identity when your game needs them.

Create a free auth project → Guest → account architecture

Identity lifecycle

POST /auth/anonymous
  → player_id = 8d…
  → access + refresh token

play as guest
  ↓
POST /auth/upgrade-guest
  → SAME player_id
  → same saves / scores / balances

Verify before you integrate

Inspect the token and upgrade rules before wiring login UI.

The public OpenAPI contract documents anonymous/email login, single-use refresh rotation, logout, guest upgrade, verification/reset, Google/GitHub/Discord OAuth and Steam Web API ticket login. The important part is the trust boundary, not the number of buttons on a login screen.

Live API status

A live check of the hosted API right now. No made-up uptime percentage and no hidden demo environment.

Check current status

Public API contract

The hosted HTTP surface is documented as OpenAPI. Inspect the wire format before choosing an SDK or writing an adapter.

Open the spec

MIT client SDKs

The JavaScript, Godot, Unity, and Roblox client SDK source is public. The hosted backend itself remains a managed proprietary service.

Inspect the SDK source

Documented exit path

Read what is exportable today and the written commitment for advance notice plus an export window if the hosted service winds down.

Read the exit guarantee

Guest login without lost progress

See why a guest should become a registered account in place instead of creating a second player record and migrating saves later.

Read the guest-upgrade guide

Anonymous first

Use a stable client-generated anonymous id to create or retrieve the same guest player and receive a player token pair immediately.

Upgrade in place

Attach email/password to the calling guest. The player id stays the same, so documents, leaderboard scores and economy balances do not need a migration.

Rotate and recover

Refresh tokens are single-use; reuse revokes the chain. Verification, password-reset and sign-out-everywhere flows are separate endpoints rather than application folklore.

Credential boundary

The publishable key starts auth. It is not an admin credential.

Player builds may contain the project publishable key so they can call /auth/*. The returned player access token is then scoped to that player. Secret API keys and server tokens belong only in trusted infrastructure. Keeping these roles separate is what makes “safe to ship” meaningful.

See engine-specific auth code

Optional identity providers

OAuth for web identities; Steam tickets for Steam players.

Google, GitHub and Discord use per-project OAuth apps. Steam uses Valve's different trust model: configure the App ID, publisher Web API key and ticket identity in Credentials; the client sends only a GetAuthTicketForWebApi ticket and Crux verifies it with Valve server-side.

Configure identity providers

Steam identity without a fake email

Verify the ticket with Valve, then key game data to the Crux player id.

Your Steam client calls GetAuthTicketForWebApi(ticketIdentity), hex-encodes the returned binary ticket, and sends it to POST /v1/auth/steam with the normal publishable Crux key. Crux calls Valve's publisher-only AuthenticateUserTicket endpoint from trusted infrastructure and maps the verified SteamID64 to one stable player record. The Steamworks publisher key never ships in the game.

Already logged in as a guest or email/OAuth account? Send a fresh Steam ticket to POST /v1/auth/steam/link with that player's Bearer token. The link endpoint refuses to silently merge two existing players.

See the Steam backend path → See the Steam quickstart Steamworks vs backend

First useful test

Create a guest from your actual game build, then prove the upgrade preserves identity.

Run anonymous login outside the Crux dashboard, write one player document, upgrade that guest to an email/password account, and confirm the same player id still owns the document. That validates the flow your players will actually experience.

Run the auth flow → Pair auth with cloud save