Production checklist

Everything to verify before you ship a MusterBox-connected game.

Work through this list before moving to production traffic.

Game setup

• Game is published in the MusterBox console (unpublished games refuse to issue SDK sessions with a 403).
• A game key exists with the session scope and the correct allowedOrigins for every environment you use.
• You intentionally selected the right environment per base URL — sandbox and production credentials are not interchangeable.

Session and match flow

• Every player gets their own session from POST /api/v1/game-sdk/{gameId}/sessions — never share a session token.
• The session token is treated as single-use and never persisted.
• matchId is taken from the real match context, never hard-coded.
• Result outcomes are one of PLAYER_A_WIN, PLAYER_B_WIN, DRAW, and only the player’s actual claim is sent.
• Your UI communicates pending vs. the final reconciliation decision.

Authentication

• Tokens are handled only by the SDK; your code never inspects or verifies JWT signatures.
• On SessionNotAuthenticated you re-authenticate or surface an error — never fall back to unauthenticated privileged calls.
• logout is always attempted on session end so the server revokes the session.

Purchases (if used)

• Purchases are driven exclusively through the SDK’s PurchaseClient.
• You never hand-roll a purchase request.
• VerifyRequest carries a unique idempotencyKey per authorized withdrawal.
• The verify call is never retried (single-shot session consumption).

Security posture for web builds

• The gameKey stays in a browser-safe, org-scoped location — it is origin-locked, never embedded in mobile binaries.
• You treat the browser as untrusted and rely on the backend for every decision that matters.
• You do not log tokens, PINs, or wallet material anywhere client-side.

Observability

• SDK diagnostics are captured on failure (getDiagnostics and native capture_diagnostics equivalents).
• EnvironmentError, transport, and protocol errors are mapped to SDK error codes for monitoring.

Before releasing packages publicly

The SDK team currently distributes engine packages as local tarballs (dist/). npm (@musterbox/sdk-js, @musterbox/sdk-wasm) and crates.io publication are not yet live. Until they are:

• Vendored builds pin the exact package version (1.0.0) and ABI (1.2.0).
• Native plugins are built from a tagged SDK source revision.

Gate

When every item above is checked, you are ready for a sandbox → staging → production promotion following the SDK versioning guidance.