Authentication
- POST /api/v1/user/login — credential exchange → access + refresh tokens
- POST /api/v1/user/register — account creation (platform/e2e surface)
- POST /api/v1/auth/validate — refresh-token rotation
- POST /api/v1/user/s/logout — server-side session revocation
Game SDK
- POST /api/v1/game-sdk//sessions — issue a single-use match session
- POST /api/v1/game-sdk//results — submit a result claim
Secure purchases (SDK-mediated)
- POST /api/v1/security/pin-session — mint a one-time PIN session
- POST /api/v1/security/pin-session//verify — verify the PIN (single-shot)
- POST /api/v1/security/events — best-effort security-event log
Environments
The OpenAPI document uses these as servers and writes every path with the
/api/v1 prefix, exactly as the SDK resolves URLs
(control-plane-base + /api/v1).
Authentication model
Every endpoint except register/login uses the bearer access token returned from login. Game SDK routes additionally require thex-game-key header
(and results require the single-use x-session-token).
Which clients should call the API directly?
The examples in the API pages assume an authenticated session. The easiest
way to obtain tokens in a scratch environment is a player login against
sandbox host.
