Onboard a web app — Crossdeck University

1 What onboarding is & why it matters

Four screens to a live heartbeat

Everything in Crossdeck — identity, entitlements, revenue, errors — rides on one SDK sending verified signals from your app. Onboarding exists to get that SDK installed and prove it's alive. It never asks for anything it doesn't need: you name a project, tell it where your app runs, register the app, and paste a snippet. The moment your first heartbeat lands, you're done and the dashboard switches to real data.

2 The four screens, button by button

What each step actually does

1

Name your project

You give the project a name (like Acme App), choose your business model — Subscriptions, One-off Payments, both, or analytics & error monitoring with no payments — and pick an app category. One project holds every platform you ship, so this is named once for the whole product, not per app.

Project nameBusiness modelApp category

2

Where does your app run?

This is the screen that defines the rest of your onboarding. You pick Web — "browser apps and Node backends — Next.js, Vite, Express, Lambda, and more". That single choice is how Crossdeck identifies your stack and decides which app step and which snippet come next.

iOS sits right beside it for native apps, and Android is marked Coming soon. Payment rails aren't here — they're optional and slot in later from the dashboard.

WebiOSAndroid · Coming soon

3

Register your web app

You pick your frontend stack, and optionally a backend stack — or choose Skip backend if every user reaches your app through a static site or single-page frontend. There's no domain to type: Crossdeck auto-registers your allowed origin from the SDK's first heartbeat.

On submit, Crossdeck issues this app's appId and a publishable key. The key is shown once — if you lose it, you refresh and rotate. It's safe to embed in browser code; it can't grant access on its own.

Frontend stackBackend stack · optionalGenerates appId + key

4

Install the SDK

Now you get the install snippet, already wired to your appId and key. The screen sits on "Waiting for your first SDK" while you add it to your app. When your app boots and the heartbeat lands, the surface flips to connected and a Continue to dashboard button appears. That handshake is the whole point of onboarding.

Waiting for your first SDK→ Connected

3 How your stack is identified

Pick Web, get the web SDK

The platform you choose on screen two, plus the framework on screen three, is the entire basis for what you receive. Because you picked Web, Crossdeck hands you the @cross-deck/web package and a browser-shaped snippet — never a Swift one. That's why this onboarding looks different from the iOS path: same four screens, a different fork at "where does your app run?".

It also means the publishable key you got is the right kind of key — a public client key, safe to ship in a bundle — rather than a server secret. Crossdeck shapes the credential to the stack, so you can't accidentally paste the wrong one.

4 The snippet you end up with

One install, one init, one heartbeat

Add the package, then initialise once when your app boots. It takes three things — the appId for this app, the publishable key from screen three, and the environment so sandbox traffic never pollutes production:

Install · @cross-deck/web

npm install @cross-deck/web

Initialise once at boot

import { Crossdeck } from "@cross-deck/web";

Crossdeck.init({
  appId: "app_web_acme01",
  publicKey: "cd_pub_live_xxx",
  environment: "production",
});

Run your app and the session lands live on the dashboard within seconds — that's the heartbeat onboarding was waiting for, and the proof your web app is wired correctly.

app.cross-deck.com · live

Web · connected

Your first verified signal just landed — onboarding is complete and the dashboard switched to real data.

Open the live map in your dashboard