Quick start

Your PlayGenus SDK arrives as a ZIP: one generated source file, a README, and your API key already embedded. Because it's generated from your approved tracking plan, you get typed methods for your events — not a generic track(string, dict) you have to remember the conventions for.

No ZIP yet? That comes out of onboarding — the tracking plan has to exist before there's anything to generate an SDK from.

Which SDK goes where

The reasoning behind the split is on Choosing your SDK. The short version: anything involving money or authoritative game state should come from your server; everything about the device and the player's hands-on experience comes from the client.

Unity (C#)

Drop PlayGenusClient.cs into Assets/Plugins/PlayGenus/ and initialise it once, in your first scene:

// Initialise — call once at game start
PlayGenus.PlayGenusClient.Init("pgn_live_your_api_key");

// Track events using your generated, typed methods
PlayGenus.PlayGenusClient.ScreenView("main_menu");
PlayGenus.PlayGenusClient.TutorialStep("welcome", "Welcome Screen", 1, 8);

That's genuinely it. Sessions, device context, crash reporting, batching, and offline queueing are all automatic — Event delivery covers what happens under the hood. There's no shutdown call either; the SDK flushes itself when the app pauses or quits.

If the defaults don't suit you:

PlayGenus.PlayGenusClient.Init("pgn_live_your_api_key", new PlayGenus.PlayGenusClient.Config
{
    FlushIntervalSeconds = 15f,  // send every 15s instead of 30s
    MaxBatchSize = 100,          // larger batches
    Debug = true                 // log what the SDK is doing
});

Java (server)

Drop PlayGenusServer.java into your server's source tree and initialise it at server start:

// Initialise — call once at server start
PlayGenusServer.init("pgn_live_your_api_key");

// Track events using typed methods
PlayGenusServer.getInstance().purchaseCompleted("player-42", "txn-123", "com.game.gems", ...);
PlayGenusServer.getInstance().progressionComplete("player-42", "world1_level12", ...);

// On server shutdown — flush remaining events
PlayGenusServer.getInstance().shutdown();

Optional configuration:

PlayGenusServer.init("pgn_live_your_api_key", new PlayGenusServer.Config()
    .flushIntervalMs(10000)     // send every 10s instead of 5s
    .maxBatchSize(100)
    .debug(true)
);

Node.js / TypeScript (server)

Drop PlayGenusServer.ts into your server project:

import * as PlayGenus from './PlayGenusServer';

// Initialise — call once at server start
PlayGenus.init('pgn_live_your_api_key');

// Track events using typed functions
PlayGenus.purchaseCompleted('player-42', 'txn-123', 'com.game.gems', ...);
PlayGenus.progressionComplete('player-42', 'world1_level12', ...);

// On server shutdown — flush remaining events
await PlayGenus.shutdown();

Optional configuration:

PlayGenus.init('pgn_live_your_api_key', {
  flushIntervalMs: 10000,
  maxBatchSize: 100,
  debug: true,
});

Everything else — REST

If you're on an engine or stack we don't generate an SDK for yet, send JSON batches straight to POST /v1/events against the same schema. The full format lives at REST API & event format — it's small enough to implement in an afternoon, and we're happy to help you work out the right shape for your setup.

Dry-run before you ship

There's a validation endpoint, POST /v1/events/validate, that checks a payload against your tracking plan and returns per-event errors without storing anything. Point your QA build or CI pipeline at it before release — it catches the "oops, that property is a string now" class of bug while it's still cheap.

Next steps