Keep Steamworks. Give your Steam player a game-owned backend identity.
Crux verifies GetAuthTicketForWebApi tickets with Valve from trusted infrastructure, maps the returned SteamID64 to one durable Crux player, and gives that player structured saves, leaderboards, live config and other backend state that can outlive a lobby or server process.
The Steam publisher Web API key stays server-side. Your player build receives only the normal publishable Crux key and creates short-lived Steam tickets through Steamworks.
Steam client
GetAuthTicketForWebApi("crux")
│ short-lived ticket
▼
Crux /v1/auth/steam
│ server-only publisher key
▼
Valve AuthenticateUserTicket
│ verified SteamID64
▼
Crux player_id
saves / stats / leaderboards
economy / live config / social Inspect the Steam boundary before you wire it into the game.
The client SDKs are MIT licensed, the auth routes are public OpenAPI, and the Steam publisher credential is kept behind the customer control plane rather than shipped in the game.
Live API status
A live check of the hosted API right now. No made-up uptime percentage and no hidden demo environment.
Check current statusPublic API contract
The hosted HTTP surface is documented as OpenAPI. Inspect the wire format before choosing an SDK or writing an adapter.
Open the specMIT 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 sourceDocumented 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 guaranteeSteam SDK helpers
Use the JavaScript, Unity, Godot or Unreal helper for Steam ticket login/linking, or call the two public REST routes directly.
Inspect the Steam quickstartSteamworks and a game backend solve different parts of the stack.
Steam already has identity tickets, lobbies, networking/SDR, Cloud, stats, Inventory and commerce surfaces. Crux is useful when your game needs a durable account/data/control layer beside those services, not as a reason to replace them.
Keep Steam-native
- Steam account and Web API authentication ticket creation
- Steam lobbies, friends/invites and Steam Datagram Relay
- Steam Cloud when file sync fits your save model
- Steam Inventory / Wallet flows when they fit your economy
- Steam server discovery where it fits your dedicated-server model
Add in Crux where needed
- Server-verified Steam ticket → stable game-owned player id
- Structured/versioned cloud-save and project documents
- Backend-owned stats, achievements and leaderboards
- Trusted-server economy mutations and inventories
- Live Config, social relationships and server registry
No fake email. No client-supplied SteamID.
Configure the Steam App ID, publisher Web API key and ticket identity once in the Crux Credentials page. The key is write-only after save. A player build then asks Steamworks for a Web API ticket using that exact identity and sends only the ticket to Crux.
Crux verifies the ticket with Valve and keys your game data to the returned SteamID64 mapping. If the player already has guest/email/OAuth progress, use the link call instead of creating a second player.
- Create the project and open Credentials → Steam player identity.
- Store the Steam App ID and publisher Web API key; choose a ticket identity such as
crux. - Call Steamworks
GetAuthTicketForWebApiwith that same identity from the game. - Hex-encode the returned ticket bytes and call the SDK
loginSteamequivalent. - Use the returned Crux
player_idfor durable game-owned state.
Do not throw away the guest save when Steam becomes available.
POST /v1/auth/steam is a login: it resolves the Steam identity to its linked Crux player, creating one only on first use. POST /v1/auth/steam/link is different: it requires the existing player's Bearer token and attaches the verified Steam identity to that player. The mapping is one-to-one per project, so Crux refuses silent account merges.
Steam authentication does not mean “replace Steamworks.”
Crux does not proxy Steam Friends, replace Steam lobbies/SDR, mirror Steam Inventory, or allocate your entire dedicated-server fleet just because it can verify a Steam ticket. Keep each Steam-native service that fits. Use the verified identity bridge when a trusted game-owned backend needs to know which Steam account is making the request.
Read Steamworks vs game backend →Verify one real Steam player, then write one durable document.
That proves the only integration boundary that matters: Valve established the Steam identity, Crux resolved the stable game player, and your backend state is no longer keyed to an untrusted client-supplied SteamID.