@uplifto/sdk

@uplifto/sdk

Typed npm loader for integrating Uplifto into Single Page Applications (React, Vue, Next.js, Nuxt). The package provides a thin init() wrapper and TypeScript-typed event constants. All SDK business logic loads from the Uplifto server at runtime.

Installation

npm install @uplifto/sdk

Quick Start

import { init, Events } from '@uplifto/sdk';

// Initialize — call once at app startup
const uplifto = init({ token: 'YOUR_PROJECT_TOKEN' });

// Track conversion events (typed autocomplete)
uplifto.track(Events.DEPOSIT, { amount: 100, currency: 'USD', method: 'card' });
uplifto.track(Events.REGISTRATION, { method: 'email' });
uplifto.track(Events.GAME_START, { gameId: 'sweet-bonanza', provider: 'super-provider' });

Versioning — npm vs browser

The SDK reports a sdkVersion field with every error event. The value depends on how the SDK was loaded:

• npm consumers (this package — @uplifto/sdk): sdkVersion equals the version from package.json (e.g. "0.6.0"). This bumps only on npm publish, so it matches exactly the version the operator installed.
• Browser / CDN consumers (snippet loader and main sdk.js bundle served from our CDN): sdkVersion has the form "<browserVersion>+<gitShortSha>", e.g. "0.6.42+abc1234". The browserVersion counter lives in sdk-version.json and is incremented by CI on every browser-bundle build (scripts/bump-browser-version.mjs); the build SHA is stamped via the SDK_BUILD_SHA env var (or git rev-parse --short HEAD fallback).

Why two formats: package.json only bumps on npm publish, but the CDN bundle redeploys on every backend release. Without the separate counter, every snippet error would land under the same pkg.version in NR Errors Inbox and regression triage after a CDN deploy would be impossible. The composite +<sha> follows the SemVer 2.0.0 build metadata convention — the field still validates as semver against the public /v1/errors payload schema.