Connect OneRoster roster data to Kastr
Kastr implements OneRoster 1.1 and 1.2 REST reads and a CSV ZIP import for its communications roster. Use Integrations, OneRoster to configure a REST connection or upload a full CSV export, choose schools, preview the changes and apply them. This is a supported subset of roster data, not a claim of full OneRoster conformance or 1EdTech certification.
| Data | REST | CSV ZIP | Kastr use |
|---|---|---|---|
| Schools | orgs | orgs.csv required | Active school organisations, limited to the selected schools |
| People | users | users.csv required | Students, linked guardians and staff records |
| Classes | classes | classes.csv required | Classes in the selected schools |
| Enrolments | enrollments | enrollments.csv required | Current student class enrolments and teacher class assignments |
| User roles | role in 1.1; roles in 1.2 | roles.csv required for 1.2 | Role types, school associations and current role dates |
| Guardian links | users.agents | users.agentSourcedIds | Links in either direction between an included student and a guardian-role user |
| Manifest | Not applicable | manifest.csv required | Version and consumed-file bulk checks; validation is not a full conformance check |
| Other collections | Not requested | Not mapped | Courses, academic sessions, demographics, resources and gradebook data are not imported by this connector |
REST connection and scheduling
Select version 1.1 or 1.2, the provider base URL and credentials. OAuth 2 client credentials supports HTTP Basic or form-body credentials. Signed requests use OAuth 1.0a with HMAC-SHA256 and do not need a token URL. The saved client secret is encrypted with AES-256-GCM and is not shown again.
Production requests use public HTTPS addresses, block specified private and reserved address ranges, and do not follow redirects. Kastr reads orgs, users, classes and enrollments using limit/offset pagination.
Manual syncs require a preview and apply by the same administrator within 30 minutes. Scheduled REST syncs apply automatically after the first successful manual apply, if the source is enabled, automatic sync is on, credentials remain available and the production worker is configured for that organisation. The default schedule is 06:00 in the organisation time zone; the hour can be changed. The current worker handles the organisation bound to its dispatch API key. CSV uploads are manual and are not collected over SFTP.
CSV files and validation limits
Upload a ZIP containing orgs.csv, users.csv, classes.csv and enrollments.csv. Include manifest.csv and, for a 1.2 export, roles.csv. Both are required for their respective versions. The manifest must declare version 1.1 or 1.2.
The upload limit is 2 MiB; the ZIP reader allows up to 64 entries and 50 MiB of selected CSV contents. Use a full export. The parser requires bulk declarations for all consumed required files, including roles.csv in 1.2. Missing or invalid declarations, malformed normalised rows and duplicate collection identities are rejected. Review counts and omissions before applying; acceptance is not proof that a file is a valid or complete OneRoster bulk export.
Kastr does not read relationships.csv. CSV guardian links use agentSourcedIds on users; 1.2 roles.csv supplies user roles and organisation associations. Courses and academic sessions are ignored, so no enrolment dates are inferred from terms.
Mapping, matching and contact handling
Stable sourcedIds link source records to Kastr records. Existing people can also be adopted by an unambiguous email match inside the organisation. Adult source records merge only when they share a valid normalised email and the same normalised name. Students do not merge. A shared email belonging to different people is kept on one resulting record; the others have no source email. An address already owned by another Kastr person is not reassigned.
The connector uses sms when present, otherwise phone, and normalises ten-digit numbers to +1. Invalid source contacts are omitted from the mapped input. Missing or invalid replacement contacts do not clear a contact already stored in Kastr. A changed phone number does not inherit SMS consent. Names remain separate from the preferred first name.
Language is read from recognised metadata keys, with a top-level language fallback. The sync changes the stored language only when its value matches the last source value or the default used by the engine; it does not have a separate record proving who chose that value.
New guardian roles default to full custody. An existing local emergency-only restriction is preserved on adoption and later managed OneRoster syncs. This connector does not import contact restrictions or emergency-only status. Review guardian eligibility in the source and do not assume a separate contacts file is automatically merged.
Withdrawals and safeguards
OneRoster sync uses the connector preview/apply engine, not the public JSON roster endpoint. A read marked incomplete suppresses withdrawals. For reads marked complete, the engine ends managed roles and active enrolments in linked classes that are absent from the mapped roster; person, school and class records remain.
When at least ten active roles and enrolments are counted as managed, ending more than half requires explicit approval. Scheduled runs are held without applying changes; an administrator must review a fresh preview and approve. Exactly half, or fewer than ten managed records, does not trigger this threshold. A scheduled read has up to three attempts per scheduling window, spaced at least an hour apart.
Repeated REST records, missing identities, invalid or changing totals, skipped malformed records and unresolved links suppress withdrawals. CSV uploads require explicit bulk declarations and reject malformed normalised rows. These checks cannot prove that a provider supplied every record and do not establish full conformance.
Questions people actually ask
Do I need to convert OneRoster files to JSON first?
No. Upload the OneRoster CSV ZIP under Integrations, OneRoster, or configure a supported REST connection. The custom JSON roster API is a separate option.
Does Kastr support both 1.1 and 1.2?
The connector implements both versions for the documented subset. It does not implement every OneRoster collection or establish certified conformance.
How are guardians linked?
Through agents on REST user records and agentSourcedIds in CSV users, in either direction between an included student and a guardian-role user. Kastr does not consume relationships.csv.
What if sourcedIds change?
Some records can be adopted by existing identifiers or unambiguous email matches, but others can become new records and withdrawals. Preview the actual changes. Do not assume every ID change duplicates everyone or that the mass-withdrawal threshold always fires.
Is this a certified OneRoster consumer?
Kastr does not claim 1EdTech certification. The implemented subset, conformance testing and formal certification are separate matters.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers or add-on modules. Normal messaging is included under a published fair-use allowance, with transparent cost recovery only above it.