Rooster LRS

Rooster LRS makes your WordPress site an xAPI Learning Record Store (LRS). Learning applications, e-learning packages (xAPI and cmi5), simulators and learning management systems send their xAPI statements to it, and reporting tools read them back. The records stay in your own database, in the plugin's own tables, and nothing is sent anywhere else. Website · Documentation · Rooster LMS What it does

• The xAPI resources under /wp-json/rooster-lrs/xapi/: statements (store, query, void), State, Activity Profile, Agent Profile, Activities, Agents and About.
• xAPI 1.0.3 and xAPI 2.0 (IEEE 9274.1.1) at the same endpoint, chosen by the X-Experience-API-Version header.
• Strict statement validation with clear error messages that name the property and the rule.
• xAPI Profiles: statements that follow the Rooster assessment or adaptive profile (quiz attempts and answers, from Rooster LMS Pro or any platform that emits them) have the profile's extensions checked against their schemas. The profiles are bundled with the plugin, so nothing is fetched.
• Every statement query parameter: agent, verb, activity, registration, related activities and agents, since and until, limit, ascending, formats exact, ids and canonical, paging with more, and statements that refer to other statements.
• Attachments (multipart/mixed) and signed statements (JWS structure, payload, and the signature when the certificate is included).
• Documents with ETags and concurrency control (If-Match / If-None-Match).
• The 1.0.3 alternate request syntax and CORS for browser-based content.
• Credentials per application (HTTP Basic): a key and a secret shown once, xAPI scopes, an authority, an expiry, revocation.
• LRS → Statements: a statement browser with filters and a "Void" action. LRS → Credentials and LRS → Settings.
• Privacy: personal-data export and erasure, erasure of one person's records by e-mail address or xAPI agent, a retention period.
• Built for large stores: its own tables, an index for every query parameter, keyset paging (tested with 100,000 statements).
• WordPress Abilities: read-only reports (activity per course, lesson, verb or learner, time spent, unfinished activities, quiz answers per question) that AI assistants on your own site, such as Rooster One's Insights Chat, can ask for; learners are pseudonymised.

Rooster LRS implements xAPI 1.0.3 and 2.0 and is tested against its own conformance suite; it has not yet been certified with the ADL LRS Conformance Test Suite. When Rooster LMS is active, the screens use its design system. Rooster LRS works without it. Endpoint and credentials

1. Go to LRS → Credentials and create a credential with the scopes the application needs.
2. Copy the key and the secret (the secret is shown once).
3. Give the application the endpoint shown on that screen (for example https://example.com/wp-json/rooster-lrs/xapi/), the key as the user name and the secret as the password.

To forward statements from Rooster LMS Pro, create a credential with the scopes statements/write and define, and choose a custom authority with Rooster LMS Pro's LMS agent. Caching and security plugins xAPI requests must never be cached. If your site uses a page cache, a CDN or a caching plugin, exclude /wp-json/rooster-lrs/ (and ?rest_route=/rooster-lrs/ on sites without pretty permalinks). Some security plugins block REST API requests from visitors who are not logged in; allow /wp-json/rooster-lrs/ for xAPI clients. Some servers remove the Authorization header before PHP sees it; Rooster LRS also reads REDIRECT_HTTP_AUTHORIZATION and PHP_AUTH_USER. Multi-tenant mode For the Rooster Adaptive LMS service only, which keeps the statements of many sites in one store. It is off on every other site, where it costs nothing and nothing changes. wp rooster-lrs multi-tenant on turns it on (status and off too; off is refused while tenants exist). In this mode:

• Every stored row belongs to a tenant. A credential reads and writes its own tenant only; another tenant's statement, document or activity answers 404, and the same statement id sent by two tenants is two statements.
• Tenants and their signed credentials are created by the service's own plugin on the same site, through Rooster LRS's PHP API (RoosterLRS\Tenancy\TenantRegistry, TenantCredentials): there is no provisioning endpoint. A tenant credential may send statements and activity definitions only, at most 300 requests a minute.
• Quiz answers and engagement statements that follow the Rooster profiles are also written, in the same transaction, to two tables the service's models read (rooster_lrs_responses, rooster_lrs_exposures). wp rooster-lrs projection rebuild --tenant=<id> derives them again from the statements.
• Each tenant has its own retention period; a person's records and a whole tenant are erased through RoosterLRS\Privacy\TenantEraser.
• LRS → Statements and LRS → Credentials show every tenant, with a tenant filter and column.

1.0.0

• First version: the core LRS, xAPI 1.0.3 and 2.0 (statements, documents, attachments, signed statements, every query parameter), credentials per application, the statement browser, privacy tools and retention.
• The Rooster assessment and adaptive xAPI Profiles (JSON-LD, bundled): statements that name them have their extension values checked.
• Read-only reports as WordPress Abilities for AI assistants on the site (Rooster One's Insights Chat): activity per course, lesson, verb or learner, time spent, activities launched but never completed, and quiz answers per question, quiz, item or skill; learners pseudonymised.
• Multi-tenant mode for the Rooster Adaptive LMS service (off by default): tenant scoping, tenant credentials issued in-process, the answer and exposure tables with their rebuild, erasure and retention per tenant.