How to sync ClassLink Roster Server data with Kastr
ClassLink Roster Server already turns your SIS into OneRoster-shaped files for every other application you run. Reusing that output is the least work available to a ClassLink district. This page covers where to have it deliver, the ordering rule that stops Kastr reading a half-written file, and the ClassLink features we do not support.
| OneRoster API endpoint | CSV to district SFTP | District-side pull | |
|---|---|---|---|
| Who holds credentials | Both parties | District only | District only |
| Who initiates | Consumer pulls | Roster Server pushes | Your job pulls |
| Kastr support | Not built — we do not pull | Recommended | Supported |
| Partial-file risk | Low | Real — needs an ordering rule | Low |
| Visibility for the district | Low | Full — the file is on your disk | Full |
| Effort to stand up | n/a | 1–2 hours | 4–6 hours |
| Where it fails | n/a | Cron and file timing | Token handling and your code |
Kastr never pulls. There is no consumer that authenticates to your Roster Server API and fetches records, which is why the first column is unavailable rather than merely unrecommended. The trade is deliberate: we cannot hold a credential we never receive, and a district can revoke our access by turning off a cron job it owns.
The recommended pattern
Have Roster Server write its OneRoster CSV set to an SFTP location your district controls. Have a cron job on a district host POST the bundle to /api/v1/roster/sync using the MIT-licensed Kastr CLI or curl. That is the entire integration, and it typically takes an hour or two once someone has decided which directory to use.
The properties worth noticing:
- Credentials stay with you. Kastr holds no ClassLink credential and cannot reach your Roster Server. The only secret in play is a Kastr API key, generated by you, SHA-256 hashed at rest on our side, displayed exactly once at creation.
- The file is inspectable. It sits on your disk before it goes anywhere. When a count looks wrong, you can open it.
- You can stop it. Turning off the sync is
crontab -e, not a support ticket.
Which files Roster Server emits and what Kastr does with each is set out in full on the OneRoster page. Short version: orgs, users, enrollments and the guardian edges are read; demographics and the gradebook files are ignored.
The ordering rule: never POST a file that is still being written
This is the operational detail that no marketing page carries and that your network engineer will ask about in the first implementation call.
Roster Server writes its output on a schedule. Your cron job reads it on a schedule. If those two schedules overlap even occasionally, the job eventually reads a file that is half-written — which parses cleanly as CSV, contains a fraction of your district, and looks exactly like a mass withdrawal.
Three ways to prevent it, in increasing order of robustness:
- Gap the schedules generously. If Roster Server finishes by 01:30, POST at 03:00. Cheap, and adequate for most districts.
- Write to a temporary name and rename on completion. Rename is atomic on the same filesystem, so the reader either sees the complete file or no file at all. Have the POST job exit quietly when the expected filename is absent.
- Use a marker file. Roster Server, or a wrapper script, touches
readyafter the last byte is written. The POST job checks for the marker, POSTs, then deletes it. This also gives you a free alert: a marker that never appears means the export failed.
And if all three fail, the guardrail catches the catastrophic case. A run that would withdraw more than 50% of active records aborts as aborted_guardrail and writes nothing. Treat that as the seatbelt, not the driving. A 40% truncation passes the guardrail and is still a bad night.
Cadence and drift
Two schedules already exist before you add a third: your SIS's own export window, and Roster Server's processing window. The Kastr POST is the third and must come last.
A workable ordering for a typical district: SIS export completes by 00:30, Roster Server processes and writes by 01:30, marker file appears, POST runs at 02:00, sync completes in minutes. If any stage slips, the marker approach means the POST simply does not run that night, and yesterday's roster stands — which is a far better failure than a partial one.
Drift is the thing to watch over a school year. Export windows lengthen as enrolment grows; a job that finished at 01:15 in September finishes at 01:45 in February. Alert on the gap between stages rather than on absolute times, and alert on a missing sync rather than trusting that no news is good news.
Run twice daily for the first three weeks of the school year, when enrolment churn peaks and a family enrolling on Tuesday morning should not wait until Wednesday to be reachable. Run manually during rollover.
What ClassLink features Kastr does not use
No LaunchPad SSO. Kastr does not appear in LaunchPad and cannot be launched from it. Staff and families authenticate with a magic link — single use, fifteen-minute lifetime, bound to the requesting device, with no account enumeration on the request endpoint. There is no SAML, no OIDC and no MFA anywhere in the product.
No OneClick or password-vaulting integration. Nothing to configure and nothing to point at.
No ClassLink Analytics participation. Kastr does not report usage into ClassLink's analytics products.
No certification. Kastr is not a ClassLink-certified application. You do not need us to be: Roster Server writing files to your own SFTP is a district-side configuration that involves no vendor relationship at all.
The reason the SSO answer is a flat no rather than a roadmap: the largest population on a school communications platform is guardians, who hold no district accounts and cannot use LaunchPad. Portal SSO solves sign-in for staff and students, a minority of the people this system reaches. It is a real gap for staff daily use and we would rather state it here than have it emerge in your third call.
Questions people actually ask
Can families log into Kastr through ClassLink LaunchPad?
No. Kastr is not in LaunchPad and supports no SSO of any kind — no SAML, no OIDC, no MFA. Authentication is a magic link with a fifteen-minute single-use token bound to the requesting device. Guardians hold no district accounts in the first place, which is the design reasoning, though it is a genuine friction for staff.
Does ClassLink Roster Server pass guardian contact information through to Kastr?
Whatever your SIS gives it and your configuration exposes. Roster Server is a normaliser rather than a source, so guardian phone coverage depends on the SIS extract behind it and on your share settings. Check the count of guardian phone numbers in the output before you rely on it; if it is thin, add a small direct SIS extract for contacts.
Should ClassLink deliver by API or by CSV to SFTP?
CSV to an SFTP location your district controls. Kastr never pulls from a Roster Server API, so the API destination is not an option for us. The SFTP pattern also keeps every credential on your side and puts the file somewhere you can open when a number looks wrong.
How do I make sure Kastr never reads a half-written file?
Have Roster Server write to a temporary name and rename on completion, since rename is atomic on the same filesystem, or use a marker file that the POST job checks for. Gapping the schedules by ninety minutes works too and is the least robust of the three. The 50% withdraw guardrail is the backstop, not the plan.
Does Kastr need to be a ClassLink-certified vendor for this to work?
No. We are not certified and it is not required. Roster Server writing OneRoster files to your own SFTP is a district-side configuration involving no vendor relationship. The only Kastr-specific step is a cron job POSTing the result with an API key you generated.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.