Core Concepts

Identity

PlayKit has one identity model: a single PlayKit account. Any signed-in user can build games and play games with the same account — there is no separate "developer" account or "player" account, and no wall between the two. What differs is not who you are but what a credential is allowed to do, which is expressed through scopes.

Game ID

Every application registered on PlayKit has a unique Game ID. It scopes all AI calls, player data, and billing to your specific game. You configure it once during SDK setup — it is not a secret.

Credentials

PlayKit recognizes two kinds of credentials, distinguished by where they live and what they are for:

API keys

You mint API keys from the dashboard and attach scopes to each one — for example full for unrestricted server calls, or a narrow scope such as analytics:read for a reporting job. Use API keys for anything that runs on hardware you control: your backend, your editor while developing, or your CI pipeline.

Player credentials (device auth)

At runtime, a shipped game never carries an embedded key. Instead, each player obtains their own short-lived player credential automatically through the device auth flow. Costs for those calls are deducted from the signed-in player's balance.

Authentication Flows

Device Auth (runtime player credential)

This is how a running game authenticates the player. The SDK handles it automatically — nothing is embedded in the build.

1. SDK initiates a device auth session and receives an auth_url
2. Player opens the URL in a browser and signs in (email or phone verification)
3. SDK polls for completion and receives the player credential
4. The credential is stored locally and reused on subsequent launches

This flow is PKCE-based and works in browser, desktop, and mobile environments.

Steam Authentication

For games distributed on Steam. The SDK exchanges the player's Steam session ticket for a PlayKit player credential via PlayKit_SteamAuthManager (Unity) or Steamworks integration.

Credits

PlayKit uses a unified credit system denominated in USD.

Player Billing

By default, AI calls in production are charged to the player's wallet. Players accumulate credits through:

• Daily credit refresh (a small amount added automatically each day)
• In-app purchases (via Steam IAP or other channel integrations)

Account Billing

During development, when you call the API with one of your own API keys, all AI calls are charged to your account. This lets you test without requiring players to have a balance.

Some games choose to keep account billing enabled in production, effectively making the game "free to play" for players. This is configured per-game on the dashboard.

Channels

Credits are scoped by distribution channel:

• standalone — Default channel for direct distribution
• steam — Players on Steam have a Steam-specific wallet
• ios, android, xbox, playstation, nintendo, epic — Platform-specific wallets

A player's credits in one channel do not carry over to another.

Model Aliases

Rather than hardcoding specific model names, the SDK supports default model aliases that automatically resolve to the best available model for that category:

Using aliases instead of specific model names means your game automatically benefits from model upgrades without code changes. You can override these with a specific model name in the SDK configuration or per-request.

Content Moderation

PlayKit applies automatic content moderation to AI inputs and outputs based on your game's configuration. Moderation categories include illicit content, sexual content, hate speech, and violence. You can configure the moderation policy for your game on the dashboard.

Next Steps

• AI Models — Full list of available models and their capabilities
• Credits & Costs — How billing works in detail
• SDK Comparison — Which SDK is right for your project