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 IP
- Platforms embedding courses in-app
- L&D teams standardizing playback
How it 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 control
A runtime built for control and reliability.
Four launch paths
Session-based, dispatch, public package, and VR session paths — 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 paths
- Signed, short-lived launch/session tokens
- Strict, server-side session update validation
- Idempotent completion callbacks + postback URLs
POST /v1/packages/pkg_01HX/launch
{ "user_id": "lee@acme.com" }
← 200 · session opened
{ "session_id": "sess_9Q2X",
"launch_url": "…/player/sess_9Q2X",
"expires_in_seconds": 14400 }- Launch availability · reported on /status
- Status page
- Launch availability · reported on /status
- Completion callbacks
- Fast
- Completion callbacks
- Default session token TTL · configurable
- 4h
- Default session token TTL · configurable
- Cross-device, by default
- Resume
- Cross-device, by default
Status, limits and plans
- Status
- Available
- Plans
- Included on every plan. See plans
- Limits
- SCORM 1.2 and SCORM 2004 packages
- Session tokens are short-lived: 4 hours by default, configurable
- Upload size: 2 GB (Free, Starter) · 5 GB (Growth) · 10 GB (Scale, Enterprise)
- Docs
- Launch your first session
Questions about Hosted player & runtime
What does a hosted SCORM player do?
How do launch URLs and resume work?
POST /api/v1/packages/{packageId}/launch with a user_id returns a session_id and a launch_url carrying a short-lived token (4 hours by default). Suspend data is persisted, so a learner who comes back resumes where they left off.Do I need my own LMS?
PAIRS WITH
Works with
- Available
SCORM Dispatch
The player is what a dispatch launches in your customer’s LMS.
- Available
xAPI 2.0 LRS
Every session reconciles into the integrated Learning Record Store.
- Available
Analytics & completion
Sessions become live telemetry — progress, scores, and pass rates.