---
title: "Scobot"
description: "SCOBot is a JavaScript wrapper that sits between courseware and the SCORM run-time API, so that content authors write setInteraction() and setBookmark() rather than hand-building cmi.interactions.3.learner_response strings. It has been maintained by Cybercussion since 2009 and reached version 5 as a rewrite in ES modules with a Vite build, ESM and UMD bundles, and Vitest tests."
canonical_url: "https://scorm-tools.com/tools/scobot"
last_updated: "2026-10-31T10:22:01.454Z"
---

SCOBot is a JavaScript wrapper that sits between courseware and the SCORM run-time API, so that content authors write `setInteraction()` and `setBookmark()` rather than hand-building `cmi.interactions.3.learner_response` strings. It has been maintained by Cybercussion since 2009 and reached version 5 as a rewrite in ES modules with a Vite build, ESM and UMD bundles, and Vitest tests.

Its distinguishing feature is the polyfill layer. The same course code runs against SCORM 1.2 and 2004 because the library translates the data model in both directions — response encoding, latency and timestamp formats, single `lesson_status` versus split completion and success. If you ship one course to clients on different LMS generations, that is the reason to choose it over a thinner wrapper.

It is not a packager, a player or a test harness. It produces no manifest, and the bundled mock LMS is for development rather than conformance checking. Nor is it a good fit if you only ever target 2004 and are comfortable with the raw API; the abstraction is then overhead.

Maintenance is healthy for a single-vendor project: commits through 2026, CI running, an active companion player. The licence is the thing to check first — CC-BY-SA-4.0 is a content licence applied to code, and its ShareAlike terms are not what most procurement processes expect.