Client SDKs

Game-client SDKs for the Kraty platform (TypeScript, Unity, and Flutter). Each speaks the /sdk/v1 surface with a client_sdk API key + per-player auth.

The client SDKs run inside your game: web bundles, Unity builds, Flutter apps. Each is fully featured on its own; pick the one matching your stack.

For your studio backend (IAP fulfilment, support tooling, manual grants, push-lobbies), use the server SDKs, a separate package family with different auth and elevated capabilities.

Pick yours

TypeScript

Web games and React Native via JS bridge. Zero deps, Node 18+ and modern browsers.

Unity (C#)

Unity 2022 LTS+. Drop-in via UPM. The same C# package compiles in plain .NET so you can integration-test outside the editor.

Flutter (Dart)

Mobile, desktop, web: anywhere Flutter runs. Pure Dart with no Flutter-engine deps, so it also runs in CLIs and tests.

What every client SDK gives you

Bearer auth from your client_sdk API key, with no separate studioId / gameId plumbing.
Per-player auth (zero-trust): every player gets a per-device secret on first run that the SDK attaches to every player-scoped call. See Authentication for the full model.
Auto-stamped idempotencyKey on every write, preserved across retries, so the server's idempotency check dedupes network replays without your code lifting a finger.
Exponential backoff + jitter on 408 / 425 / 429 / 5xx + network failures. Retry-After honored.
Sealed error codes with typed is… helpers, such as err.isLobbyForming, err.isInsufficientEntryCost, err.isPlayerSecretInvalid, …
Lobby-forming handling: when matchmaking is still filling, the backend returns 202 + error.code = 'lobby_forming'; every SDK surfaces this as the same typed exception so you can poll and retry. Lobby reads carry a botSlots projection so your UI can animate fill-up smoothly.
Adaptive grant polling + one-shot collect-all: grows the interval while empty; or use grants.collectAll() to open all crates + claim all rewards in one call.
Live leaderboard streams: eventLeaderboards.live(id) returns a Server-Sent Events subscription emitting ready, score_update, closed events.
Finalization catch-up: onFinalized fires exactly once when a board the player is on ends, whether they were online (live SSE) or away (checkFinalizations() on foreground). The reported reason distinguishes an early-ended session from a closed event window. Ideal for "your session ended, you placed Nth" result screens.
Telemetry hook: every request fires an onRequest callback you can pipe into your observability stack.

Why client and server SDKs are separate

Never embed a server_integration key in a game client. These keys can mint currency and grant items, so anyone who dumps the binary extracts them and owns every player's economy. The client SDKs (TypeScript, Unity, Flutter) deliberately do not expose /server/v1 endpoints; there is no method that can mint resources on a client SDK. The server SDKs are separate packages so accidentally embedding one in a client bundle is a visible code-review failure, not a silent security incident.

Use case	SDK	Auth
Web game, browser JS, React Native	`@kraty/sdk`	`client_sdk` + player secret
Unity game (2022 LTS+)	`@kraty/sdk-unity`	`client_sdk` + player secret
Flutter app (mobile / desktop / web)	`@kraty/sdk-flutter`	`client_sdk` + player secret
Node backend, IAP fulfilment	Node server SDK	`server_integration`
Python backend, Django / FastAPI / Celery	Python server SDK	`server_integration`

Client SDKs are safe to ship with a client_sdk key because:

The key scopes strictly to the (studio, game) it was issued under, with no cross-tenant access.
It cannot mint other keys, manage members, or read audit logs; only the SDK surface.
It alone cannot read or spend another player's resources; the per-player secret gate sits on top.
You can rotate it from the portal at any time and the SDK will pick up the new key on its next deploy.