Send · content deliveryLive

We host the runtime. You keep control.

The hosted player is the engine that actually runs your course. Whether a learner launches from a dispatch, a public link, or inside your own app, Connect serves the content, tracks the session, and resumes where they left off — then reconciles completion back to your records. The source files never leave us.

Resume where they left off Branded player shell One system of record
Hosted player · session● PLAYING
OSHA 30 · Module 4
sess_9Q2X · resumed at 64%
TRACKING
progress 64%score 88%
Completion → LRS + postback
idempotent · 184ms
QUEUED
Launch reconcile
Full session lifecycle
Resume
Sessions pick up mid-course
Short-lived
Signed tokens, not embeds
4 routes
Session · dispatch · public · VR
NEW TO THIS? START HERE

What does the hosted player actually do?

When a learner clicks play, something has to serve the course files, talk the SCORM/xAPI runtime API, and record what happened. That’s the hosted player. Instead of shipping your raw course into someone else’s system, Connect runs it from a launch session — so progress, scoring, and bookmarking are handled centrally, and you stay the single source of truth for every completion.

Content providers protecting their IPPlatforms embedding courses in-appL&D teams standardizing playback
HOW A LAUNCH WORKS

Three moments, every time a learner presses play.

STEP 01

Launch

A learner opens the course. Connect mints a short-lived, signed session token and opens the branded player — no credentials or content baked into the link.

STEP 02

Play & resume

The player tracks progress, score, and interactions against the SCORM/xAPI runtime API. Leave and come back and the session resumes exactly where it stopped.

STEP 03

Reconcile

On completion, Connect writes the result to your xAPI LRS and fires any postbacks — idempotently, so a flaky network never double-counts.

WHAT YOU GET

A runtime built for control and reliability.

Four launch routes

Session-based, dispatch, public package, and VR session routes — one runtime behind every way your content gets opened.

Resume & bookmarking

Sessions persist state, so learners continue mid-module across devices instead of restarting.

Short-lived session tokens

Each launch is authorized by a signed, expiring token — nothing reusable is embedded in the link or shell.

Branded player shell

Your logo, colors, and domain on the player chrome — playback that looks like your product, not ours.

Strict session validation

Every session update is validated server-side; malformed or out-of-order writes are rejected, not silently stored.

Graceful error handling

Token and session errors show a clear learner-facing state instead of a broken white screen — and surface in your logs.

FOR THE TECHNICAL BUYER

Sessions, not file drops.

A launch opens a Connect-hosted player and authorizes it with a short-lived signed token. The player speaks the SCORM 1.2 / 2004 runtime API (and xAPI), persists session state for resume, and reconciles completion through an idempotent callback. Connect remains the system of record — the LMS or app that launched it just sees a clean result.

  • Session, dispatch, public, and VR player routes
  • Signed, short-lived launch/session tokens
  • Strict, server-side session update validation
  • Idempotent completion callbacks + postback URLs
LAUNCH A SESSION · API
POST /v1/packages/pkg_01HX/launch
{ "actor": "mailto:lee@acme.com",
  "mode": "normal" }

← 201 · session opened
{ "session_id": "sess_9Q2X",
  "player_url": "…/play/sess_9Q2X",
  "expires_in": 900 }
See the full API
184ms
Completion callback · p95
99.99%
Launch uptime · 30 days
900s
Session token TTL
Resume
Cross-device, by default

Run your courses on a runtime you control.

Get a sandbox key and launch your first hosted session in minutes.

Get a sandbox keySee all features