Session token

You generate the token. You validate it. You decide when it dies. Zero-Dash only carries it: from the launch URL, back to your Player authorization callback, and into every debit for that session.

Requirements

Unique and non-deterministic

A random, unguessable value. Never the player ID, the account ID, an email, or anything derived from them.

At least 2 hours valid

Sliding-window expiry is preferred where your platform supports it — the token refreshes while the player is active.

Reusable for the whole session

Multiple API calls and client reloads use the same token. Single-use tokens break every reconnect.

No length limit

Any length is fine. An opaque random string or a signed JWT both work.

The token travels as a query parameter in the launch URL. Assume it will be visible in browser history, in a shared screenshot and possibly in an intermediate access log. That is exactly why it must be non-deterministic, scoped to one player, time-limited and revocable.

Choosing a format

Opaque random token
Signed JWT

A random identifier, with the session state in your store. Simple and instantly revocable.

import { randomBytes } from 'node:crypto';

async function mintSessionToken(playerId, currency) {
  const token = randomBytes(32).toString('base64url'); // 256 bits
  await sessions.set(token, { playerId, currency }, { ttl: '2h' });
  return token;
}

Revoking is a single delete. Preferred when you already run a session store.

Self-contained, no lookup on the hot path — but revocation needs a deny list.

import jwt from 'jsonwebtoken';

const mintSessionToken = (playerId, currency) =>
  jwt.sign({ sub: playerId, cur: currency }, process.env.SESSION_SECRET, {
    expiresIn: '2h',
    jwtid: randomUUID(), // gives you something to revoke
  });

Never put personal data in the payload. A JWT is signed, not encrypted — anyone holding the token can read every claim.

Validating it

Your /player callback receives the token and answers with the player’s identity:

{
  "accountId": "acct_8f2c19",
  "displayName": "Matthew S.",
  "balance": { "amount": 12.45, "currency": "USD", "updatedAt": "2026-01-29T14:05:29.678Z" },
  "subOperatorId": "9"
}

Reject the request when the token is unknown, expired, revoked, or belongs to a different player than the one the request implies. A rejected authorization stops the game from starting — which is the correct outcome.

Token validity and accountId are separate concerns. The token identifies a session; the accountId identifies the player, for life. See Account ID.

Lifetime in practice

Moment	What the token must do
Launch URL requested	Exist and be valid
Game opened, `/player` fires	Validate successfully
Player reloads the tab	Still validate — the same token is reused
Player bets, `/debit` fires	Still validate
Player wins, `/credit` fires	Irrelevant — credit carries no token and must work without a session
2 hours later, still playing	Ideally still valid via sliding expiry

This is the one that catches people: /credit and /rollback carry no token at all and can arrive days after the round. Never gate them on session validity. See Errors and retries.

Common mistakes

Using the player ID as the token

It is deterministic and permanent. Anyone who learns a player ID can open a session as that player, forever. Use random bytes.

Single-use tokens

The game reloads on reconnect, on rotation, on a resumed session. A token consumed by the first /player call breaks the second one.

Tokens shorter than the session

A 15-minute token ends the round for anyone who steps away. Two hours is the floor; sliding expiry is better.

One token shared across currencies

An account ID maps to exactly one currency. If a player holds several wallets, each needs its own session with its own token and its own account ID.

Get started

Launch games

Security

Wallet integration

Free rounds

Go live

Requirements

Unique and non-deterministic

At least 2 hours valid

Reusable for the whole session

No length limit

Choosing a format

Validating it

Lifetime in practice

Common mistakes

​Requirements

Unique and non-deterministic

At least 2 hours valid

Reusable for the whole session

No length limit

​Choosing a format

​Validating it

​Lifetime in practice

​Common mistakes

Requirements

Choosing a format

Validating it

Lifetime in practice

Common mistakes