Kraty

Server SDKs

Per-game server-side SDKs — 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're 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's 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's 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 — 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.

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 can't sneak through silently.
  • Webhook signature verificationverifyWebhook / verify_webhook helper so your receiver doesn't 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 can't 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're on a TS/JS stack, edge runtime, or your fulfilment workers are Node-based.
  • Python if you're on Django, FastAPI, Litestar, Celery, Airflow, or a data-science / ML stack.

Both maintain wire-format parity by sharing the same OpenAPI spec (openapi.server.json) — 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.

See also

  • Client SDKs — for game clients (TypeScript, Unity, Flutter).
  • Authentication — the two-key model.
  • REST API — raw endpoints if you don't want a wrapper.
  • Webhooks — full event catalog + signature verification.