Sessions

A session represents an active online client connection—user, device, app version, last heartbeat. Sessions complement activations: floating licenses limit concurrent sessions; perpetual and node-locked online licenses use sessions for live monitoring and cleanup.

Combined walkthrough: Sessions & activations guide · Perpetual online · Node-Locked online.

Session lifecycle

1. Start — SDK SessionManager opens session after successful validation/activation.
2. Heartbeat — periodic ping keeps session alive; stale heartbeats mark offline.
3. Concurrent check — floating model counts active sessions vs maxActiveUsers.
4. End — client shutdown or explicit end call releases seat.
5. Disconnect (operator) — force terminate from dashboard for stuck sessions.
6. Cleanup — remove stale offline rows after support confirms client is gone.

Global Sessions page

Sidebar: Sessions (Active Sessions). NOC-style monitoring of who is online right now.

• Live — auto-refresh while enabled (release weekends, license migrations).
• Online / offline filter — focus on live clients vs historical rows.
• Search — license key, user email, machine name, app version.
• Disconnect — remote termination; client fails on next heartbeat.
• Details panel — version string, IP/geo when collected, session id for API correlation.

Per-license Sessions tab

Same data as the global page scoped to one license—ideal for a single perpetual, node-locked, or floating key.

When sessions matter

Model	Sessions role
Floating	Primary enforcement — concurrent live sessions = seat count
Perpetual online	Visibility, abuse detection, support disconnect
Node-Locked online	One active session typical; heartbeat proves client still running
Subscription	Detect stale clients after cancellation grace
Credit-Based / Usage-Based	Optional session tracking alongside Usage tab metering

Roles

Visibility: system Admin, org Admin, product owner (API-filtered). Members/Viewers do not manage sessions.

REST topic · SDK sessions · Activations