Connect Roster Server output through OneRoster

Use Integrations, OneRoster to connect a REST endpoint or upload a full OneRoster CSV ZIP. There is no native SFTP pickup.

Connect and review

Obtain the authorised base URL, version and credentials from the provider. For a signed-request connection select Signed requests and enter the key and secret; no token URL is needed. Check the connection, select schools, preview the roster and review guardian coverage before applying.

Credentials and schedule

Kastr stores the connection secret encrypted with AES-256-GCM. Disconnect removes the saved secret and disables the connection while keeping roster links. REST sync can run nightly after the first manual apply when automatic sync and the production worker are configured. The worker currently runs for one configured organisation. Manual CSV uploads are not scheduled.

Data and safeguards

The connector reads schools, users, classes and enrolments, including guardian agents and 1.2 user roles. It does not import courses, academic sessions or gradebook data. The OneRoster guide documents identity matching, custody behaviour, withdrawal approval and the current completeness-validation limitations. Confirm these against a representative provider export before rollout.

A practical first rehearsal

Use an approved test tenant and synthetic or otherwise authorised sample data. Keep the scope to one school first. Identify the expected number of schools, classes, students, guardians, guardian links and teacher assignments before requesting the preview. The connection check establishes that the orgs collection can be read; it does not test all four collections, guardian completeness or conformance.

Inspect the preview for missing guardians, skipped records, shared emails, unexpected duplicate people and class membership changes. A valid email shared by two different adults is not a shared Kastr identity: one mapped person retains it and the other does not. An adult represented by teacher and guardian records merges only under the documented name-and-email matching rules. Test both cases rather than assuming the provider uses one record per human.

Check a family with two children, a teacher who is also a parent, a student moving classes and a guardian whose contact should no longer be used. The current connector does not clear an existing stored contact merely because it disappears from the source. It also does not import contact restrictions or emergency-only status. Existing local emergency-only restrictions are preserved through later OneRoster syncs. These are implementation limits to resolve or explicitly account for before using real-family messaging.

For a second rehearsal, change one enrolment and remove one permitted guardian link in the source, preview the results and inspect the applied roles. Re-run the unchanged feed to check stability. Do not interpret a successful preview as proof of complete data: pagination and malformed-input checks cannot prove that every source record was shared. The native withdrawal approval threshold requires at least ten active managed roles and enrolments, and a loss greater than half.

Before enabling a schedule, record the organisation tied to the deployed worker key, confirm the selected local hour and identify who will respond to a held or failed run. Verify an actual scheduled run and alert delivery. A saved connection, an On label or a fixture test alone does not establish production scheduling.

Access and certification

Confirm the provider's application approval, sharing and credential requirements directly. A working standards-based connector does not establish catalogue listing, partnership, certification or LaunchPad sign-on. This page makes no claim to those services.

Questions people actually ask

Related