Server SDKs
Per-game server-side SDKs for IAP fulfilment, grant currency / items, push pre-matched lobbies, verify incoming webhooks, look up player state. Available in Node and Python.
The server SDKs let your studio's backend drive per-game server-side actions: minting grants for IAP fulfilment, crediting wallet balances after a purchase, granting items as make-goods, revoking on chargebacks, pushing pre-matched lobbies from your own matchmaker, and verifying incoming webhooks.
They are a separate package family from the
client SDKs: different auth
(server_integration API key vs client_sdk), different
endpoints (/server/v1/* vs /sdk/v1/*), different security
posture (server keys can mint currency; client keys cannot).
Keeping them in distinct packages means
import { KratyServer } from '@kraty/server-sdk' in a web
bundle is a visible code-review failure, not a silent security
incident.
Scope: per-game server actions. Every server_integration
API key is issued for a specific (studio, game) pair and
scopes strictly to that game. The server SDKs are for things
your studio's backend does ON BEHALF OF a single game. They
are not portal-operator tooling.
What is in scope:
- Grant / revoke items, credit / debit currency on a player
- Mint manual grants (IAP fulfilment, make-goods, season-pass tiers)
- Push pre-matched lobbies from your own matchmaker
- Look up a single player's state for support tools
- Verify incoming webhooks
What is NOT in scope (and never will be on this SDK):
- Listing or creating games, studios, members
- Editing events / catalogs / reward tables / API keys / webhook endpoints
- Reading audit logs
Those are portal-operator concerns and live under /admin/v1,
consumed by the Kraty portal UI, not by your studio's
backend.
Server-side only. Never embed a server SDK or its API key
in a game client (web bundle, mobile app, Unity build). The
server_integration key can mint currency and items, so anyone
who dumps the binary extracts it and prints unlimited gold.
For game clients use
@kraty/sdk,
@kraty/sdk-flutter, or
@kraty/sdk-unity.
Pick yours
Same surface in both languages; pick by stack.
Node (TypeScript)
@kraty/server-sdk. Node 18+ or any modern JS runtime (Bun, Deno, edge). Zero runtime dependencies. Built on native fetch.
Python
kraty-server-sdk. Python 3.10+. Built on httpx with ruff + strict mypy clean for strict-mode codebases.
What every server SDK gives you
- Manual grants (
grants.create): mint currency + items + crates in one atomic, idempotent payout. - Inventory grant / revoke: platform-managed IAP item delivery + chargebacks. The only way to mint platform-managed items.
- Wallet credit / debit: IAP currency fulfilment + refunds. Credit is server-only by design (clients can spend, only servers can mint).
- Push lobbies: for studios that match outside Kraty (Steam, GameLift, Photon).
- Player snapshot: single-player support-tool view (player
- inventory + wallet + recent grants in one call).
- Idempotency conflict detection: replay an IAP receipt
with a different body and the SDK throws
isIdempotencyConflict/is_idempotency_conflict, so duplicate mints cannot sneak through silently. - Webhook signature verification:
verifyWebhook/verify_webhookhelper so your receiver does not have to roll its own HMAC. Constant-time compare, replay-window enforcement, configurable tolerance. See Webhooks. - Auto retries + idempotency-key preservation across attempts, so a flaky network cannot double-mint on retry.
- Telemetry hook: every request fires a callback you can pipe into your observability stack.
Choosing between Node and Python
Identical surface; pick by what your backend already runs.
- Node if you are on a TS / JS stack, edge runtime, or your fulfilment workers are Node-based.
- Python if you are on Django, FastAPI, Litestar, Celery, Airflow, or a data-science / ML stack.
Both maintain wire-format parity by sharing the same OpenAPI spec (see the Server API reference), so their request bodies and response shapes are byte- compatible. A service mesh that has both Node and Python services can use whichever SDK fits each service without contract drift.