LMS integration with Grout: roster, SSO, grades

Yes: Grout now connects to Moodle, Canvas or any other learning management system through the Grout Institution API. An institution can sync its rosters, put a single sign-on button inside the LMS that opens GroutApp or GroutCode with the student already signed in, and receive graded exam scores back into the gradebook. This article explains what each of those three jobs involves, what they do not involve, and how long a typical IT team should budget for them.

What "LMS integration" means here

The phrase gets used loosely, so it is worth being precise. There is no Grout plugin to install in Moodle or Canvas, and there is no vendor-side switch that "turns on" the connection. Instead, an institution gets an API key scoped to its own data and writes a small amount of code, or asks its LMS integrator to, against a plain HTTPS and JSON interface documented at the LMS integration guide.

That design is deliberate. LMS plugins age badly: they break on platform upgrades, they need one build per platform, and they run with more permission than the job needs. A short service that calls the same API from any platform is easier to review, easier to keep running, and works the same for a homegrown student portal as it does for Canvas.

Job one: roster sync

The first thing every institution needs is people. Roster sync reads students, teachers and sections from the student information system or the LMS and mirrors them into Grout.

• Each student is created once with the institution's own student id, and the API returns a generated login email. The sync stores that email; it is never derived.
• Teachers are created the same way and can then own exams and groups.
• One Grout group is kept per section. On every run the membership is replaced from the source of truth, so groups never drift from the timetable.
• Students who leave are suspended, not deleted, so their history stays intact.

A bulk endpoint takes up to 200 students per call, and each key allows 600 requests a minute by default, so a 5,000-student institution completes a nightly run in a few minutes. The generic algorithm is in the roster sync guide, with platform-specific versions for Moodle and Canvas.

Job two: one-click launch from the LMS

This is the part students notice. A link in the course, a Moodle URL activity or a Canvas module item, opens GroutApp or GroutCode with the student already signed in and already on the right exam or activity. No one-time code, no second password to remember.

Under the hood the LMS button calls the institution's own service, which asks the API for a launch token tied to that student's stored login email. The token is single-use and lives for between 30 seconds and five minutes. The browser is sent to a launch page that hands the token to the desktop app, and the app trades it for a normal session. The API key never reaches the browser, and a token that leaks is useless a couple of minutes later. Details and error codes are in the SSO launch reference.

One honest caveat: the desktop apps consume these tokens from their next release. Until then the launch page opens but the app will not complete the sign-in, so an institution building the button today should plan to test it against the updated apps.

Job three: grades back into the gradebook

Exams that are created through the API are graded in Grout, including GroutCode coding exams where a real compiler runs the student's code against hidden tests. When a submission is graded, Grout sends an exam.graded event to a webhook endpoint the institution registered. The handler verifies the signature, fetches the submission for the authoritative score and feedback, and writes it to the gradebook item that corresponds to the exam.

Webhook deliveries are signed with HMAC-SHA256, retried on a schedule if the endpoint is down, and can be replayed from the portal. A daily backfill call catches anything an outage missed. The gradebook sync guide has a working handler sketch.

Keys and permissions

Each of the three jobs should run under its own API key carrying only the scopes that job needs. A roster key cannot mint launch tokens; a launch key cannot read submissions. Every key is bound to one institution, and no request accepts an institution id, so a key cannot reach another school's data even by mistake. Keys are created by an institution admin in the portal, or by a developer the admin has invited, who gets a dashboard showing keys, webhooks and delivery logs but no student data.

How much work is it?

For a team that has integrated anything with its LMS before, roster sync is a day including testing, the launch button is an afternoon, and gradebook write-back is a day because of the webhook plumbing. An institution that only wants the launch button can ship that alone; the jobs do not depend on each other.

If part of the build is being done with a coding agent, the docs are written for that: every page is readable as markdown, and there is an llms.txt index, an AGENTS.md with guardrails and a SKILLS.md of task recipes. Before any of it goes live, read the integration best practices for keys, idempotency and monitoring, and talk to the institution team if you would like help scoping it.