SDK & API Integration Guides
Keme provides a JavaScript / TypeScript SDK plus native SDKs for Unity (C#), Android (Kotlin), and iOS (Swift). Every SDK wraps the same player-portal REST contract and exposes the same surface — login, tickets, and knowledge base — so capabilities and data models are identical across platforms. The JS SDK is the reference implementation. Choose the integration that matches your studio's stack and get your player support layer live in minutes.
All SDKs live in a single monorepo, kemegames-studio/keme-sdk, and share version v0.1.0. The underlying REST contract is documented on the REST API page.
Platform SDKs
Drop-in in-app support for web games, browser apps, and any JS runtime. Full TypeScript types included. Works with React, Vue, Svelte, and vanilla JS. The reference implementation for the Keme SDK.
A first-class Unity package for mobile and PC games. Includes a runtime uGUI support panel prefab and mirrors the JS SDK surface exactly.
Integrate drop-in Keme support into your Android game or app. Ships a KemeSupportActivity for in-app tickets and a knowledge base.
Drop the Keme SDK into your iOS or iPadOS title. Distributed via Swift Package Manager with a KemeSupportViewController and SwiftUI support.
The player-portal REST contract that every Keme SDK wraps — login, tickets, and knowledge base. Use it directly when you can't use a native SDK or want full control.
Current Versions
All Keme SDKs are published from the keme-sdk monorepo — the JS package under /js, and the Unity, Android, and iOS SDKs in their respective directories.
| Platform | Version | Artifact / Package |
|---|---|---|
| JS/TS npm package | v0.1.0 | @keme/sdk (npm) |
| Unity SDK | v0.1.0 | com.keme.sdk (UPM) |
| Android SDK | v0.1.0 | com.keme:sdk (.aar) |
| iOS SDK | v0.1.0 | KemeSDK (Swift Package) |
| REST API | v1 | https://api.kemegames.com/api/v1 |
Quick Comparison
Use the table below to compare platform requirements, authentication methods, and feature availability at a glance before choosing your integration path.
| Platform | Min Version | Auth Method | Drop-in UI | Package |
|---|---|---|---|---|
| JavaScript | Modern browsers / Node 18+ | Player Bearer token | DOM widget | @keme/sdk (npm) |
| Unity | Unity (UPM) | Player Bearer token | Runtime uGUI panel | com.keme.sdk |
| Android | Android (Gradle) | Player Bearer token | KemeSupportActivity | com.keme:sdk (.aar) |
| iOS | iOS (SwiftPM) | Player Bearer token | KemeSupportViewController | KemeSDK (SPM) |
| REST API | Any HTTP client | Player Bearer token | — build your own | api.kemegames.com/api/v1 |
Choosing the right integration
The right integration depends on your studio's tech stack, target platform, and how much control you need over the support UX. Here is a quick decision guide:
- Web game or browser-based app — Use the JavaScript SDK. Works in the browser and any JS runtime, ships full TypeScript types, and includes the drop-in DOM support widget via
openSupport(). This is the reference implementation. - Cross-platform Unity title — Use the Unity SDK. The UPM package includes a runtime uGUI support panel prefab and mirrors the JS SDK surface. A single integration covers all Unity build targets.
- Android game or app — Use the Android SDK. It ships a ready-made
KemeSupportActivityfor a native in-app support experience. - iOS game or app — Use the iOS SDK. Distributed via Swift Package Manager with a
KemeSupportViewControllerand SwiftUI support out of the box. - Custom integration or unsupported platform — Call the REST API directly with a player bearer token. Full control over login, tickets, and the knowledge base with no SDK overhead.
- Multiple platforms simultaneously — All SDKs wrap the same player-portal contract and ticket schema. You can run the JS, Unity, Android, and iOS SDKs (and the REST API) in parallel — tickets from all sources appear in the same Keme inbox.
Embedding the support widget vs. headless API
Every native SDK ships in two modes: Widget mode (a fully styled in-game overlay with ticket list, compose screen, and file attachment UI) and Headless mode (raw API methods only, so you can build your own UI on top). Widget mode is recommended for most studios because it requires no design work and matches Keme's player-facing branding automatically. Headless mode is recommended for studios that want a completely custom UX or are integrating Keme into an existing in-game menu system.
Authentication Model
Keme's SDKs are player-facing. There are no secret API keys to embed — a game is identified by its gameId, and every player action is authorised by a per-player bearer token obtained at login.
gameId
Your gameId identifies your game/app in Keme (for example game-marble-sort). You set it once when you initialise the SDK, and it is used when a player files a ticket. It is not a secret — it identifies your game, and all player data access is still gated by the player's token.
Player bearer token
After your own authentication completes, call the SDK's login() with the player's userId (which maps to the portal gameUid). The first login auto-provisions the player — there is no separate registration. Login returns a JWT bearer token (7-day expiry) that the SDK persists and attaches to every authenticated request. See the REST API reference for the exact auth endpoints.