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
Web games, React Native via JS bridge. Zero deps, Node 18+ and modern browsers.
Unity 2022 LTS+. Drop-in via UPM. Same C# package compiles in plain .NET so you can integration-test outside the editor.
Mobile, desktop, web — anywhere Flutter runs. Pure Dart, no Flutter-engine deps, so it also runs in CLIs and tests.
What every client SDK gives you
- Bearer auth from your
client_sdkAPI key — no separatestudioId/gameIdplumbing. - 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
idempotencyKeyon 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-Afterhonored.
- network failures.
- Sealed error codes with typed
is…helpers —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 abotSlotsprojection so your UI can animate fill-up smoothly. - Adaptive grant polling + one-shot collect-all — grows the
interval while empty; or use
grants.collectAll(externalId)to open all crates + claim all rewards in one call. - Live leaderboard streams —
leaderboards.live(id)returns a Server-Sent Events subscription emittingready,score_update,closedevents. - Telemetry hook — every request fires an
onRequestcallback 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 — anyone who dumps the
binary extracts them and owns every player's economy. The client
SDKs (TypeScript, Unity, Flutter) deliberately don't 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 — no cross-tenant access. - It can't 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.