Kastr integrations: how your student and guardian data actually gets in
Kastr has no native vendor connectors. Nothing here logs into your SIS. What we have is one documented endpoint, an OneRoster-shaped data model, and a diff engine that tells you exactly what a sync would change before it changes anything. This page is the mechanism, per system, including the parts we do not do.
| System | Usual export mechanism | Scheduler in the product | OneRoster output | Guardian phone reachable | Typical first sync |
|---|---|---|---|---|---|
| PowerSchool SIS | Data Export Manager, PowerQuery, plugin export | Yes | Via broker | Yes, from Contacts | 4–8 hours |
| Infinite Campus | Ad Hoc Reporting scheduled export | Yes | Yes, native | Yes, household/relationship | 4–8 hours |
| Skyward | Data Mining (SMS 2.0) or Qmlativ export | Yes | Qmlativ only | Yes, Family 1 / Family 2 | 6–12 hours |
| Aeries | Aeries Query or the v5 REST API | Yes | Via broker | Yes, CON table | 4–6 hours |
| Synergy (Edupoint) | Query / Report Designer extract | Yes | Module dependent | Yes, contact records | 6–10 hours |
| Tyler SIS | Scheduled report to SFTP | Yes | Via broker | Yes | 6–10 hours |
| Focus School Software | Scheduled report / API | Yes | Via broker | Yes | 6–10 hours |
| eSchoolPlus | Scheduled extract or Home Access data | Yes | Via broker | Yes | 8–14 hours |
| Alma | REST API or CSV export | Partial | Yes | Yes | 3–6 hours |
| Gradelink | CSV export | Manual | No | Yes | 3–5 hours |
| Clever | Secure Sync to district storage, or API pull | Yes | Yes | Often withheld | 2–5 hours |
| ClassLink Roster Server | OneRoster files to district SFTP | Yes | Yes | Depends on share config | 2–5 hours |
| Ed-Fi ODS/API | District ODS, OAuth2 client credentials | You schedule it | Ed-Fi shape, not OneRoster | Yes, DS5 Contact | 10–20 hours |
| Microsoft 365 / Entra ID | School Data Sync, Entra SCIM (beta) | Yes | SDS emits it | Staff only | 3–6 hours |
| Google Workspace | Admin SDK Directory export | You schedule it | No | Staff only | 2–4 hours |
| Google Classroom | Not a roster source — downstream of your SIS | n/a | No | No, email only, opt-in | n/a |
| Canvas / Schoology | Not a roster source — downstream of your SIS | n/a | No | No, observers are opt-in | n/a |
| Anything else, by CSV | Whatever your SIS already drops nightly | Yours | Optional | If it is in the file | 2–4 hours |
"Typical first sync" is engineering hours to a clean dry run, not elapsed days, and assumes someone in the district can already produce an export from the SIS. OneRoster availability and guardian-field coverage vary by version, module licensing and how your own instance was configured — treat the columns above as where to start asking, not as a warranty. Every row lands at the same endpoint.
Read this first: what Kastr does not have
No native connectors. There is no PowerSchool plugin, no Infinite Campus app, no Aeries certificate flow, no Skyward partnership. No Kastr code authenticates to a student information system and pulls records. Any page in this category — ours or anyone else's — that shows you a logo and implies a switch you flip is describing a partner programme, not an integration.
No SSO of any kind. No SAML, no OIDC, no Google Sign-In, no ClassLink LaunchPad, no Clever Instant Login, no MFA. Magic link is the only authentication Kastr has, for staff and families alike.
No write-back. Kastr never writes to your SIS. Not attendance, not message logs, not contact corrections. The data flow is one direction, and that is a deliberate scope decision rather than a roadmap item.
No auto-notice engine. You can configure rules for attendance or lunch-balance notices. Nothing fires them yet. Rules exist in the interface; the engine that would run them has not shipped.
No grade, school or route targeting. Today an audience resolves as either specific named people or everyone. The roster carries schools and sections, and the model is there, but the resolver does not yet segment on them. If your use case is "message the bus route 14 families", we are not there.
That list is longer than most vendors would print. It is here because every one of those items surfaces in the second technical call anyway, and finding out then is worse for both sides than finding out now.
The actual topology
Every route in the table above converges on the same four steps:
- Your SIS produces an export. It almost certainly already does — most districts have a nightly job feeding some other vendor. Kastr accepts an OneRoster-shaped CSV bundle or a flat student-and-contacts CSV. See the OneRoster field map or the plain CSV spec.
- Optionally, a broker sits in the middle. Clever or ClassLink already normalise your SIS into OneRoster shape for other applications. If you run one, use its output rather than building a second extract. The caveat is guardian phone numbers, which is covered on both pages and is the single most common surprise in this category.
- Something POSTs the file. A cron job on a district server, using the MIT-licensed Kastr CLI or plain
curl, sends it toPOST /api/v1/roster/sync. The job runs on your infrastructure with a key you hold, which means you can see it, log it, and turn it off without calling us. - The diff engine classifies every record. Each record payload is hashed with SHA-256 and compared against the stored hash. The result is a ledger of adds, changes, unchanged records and withdrawals. In dry-run mode you get the ledger and nothing is written.
The reason to describe it this plainly is that it is auditable. You can watch the file leave your network, read the ledger, and reconcile the counts against your own SIS before a single message goes anywhere.
What the diff engine does, with numbers
A worked example from a 12,410-record district file on an ordinary Tuesday in October:
- 12,410 records read, 11,975 students and 435 staff.
- 41 adds — new enrolments since yesterday.
- 388 changes — the record hash differs. Mostly phone numbers and one school changing a homeroom naming convention.
- 11,975 unchanged — identical hash, no write.
- 6 withdrawals — present yesterday, absent today.
- 0 aborts.
Now the same job on a night when the SIS export dies halfway through. The file is valid CSV. It parses. It contains 5,102 records. The engine computes that accepting it would withdraw 7,308 of 12,410 active records — 58.9% — and refuses. The run is recorded as aborted_guardrail, nothing is written, and the previous roster stands. Overriding it is a deliberate act, not a retry.
This is the failure that ends badly at other vendors, and it fails silently because every individual step reported success. The truncated file is the reason the guardrail exists.
Being precise about withdrawals
A withdrawal in the diff engine marks the enrolment record as withdrawn and writes the change to the append-only audit log. Here is the part that matters and that we are not going to bury: the send path does not yet filter on withdrawal status. The audience resolver reads the people you selected; it does not currently check enrolment state or suppression flags at send time.
In practice that means removing a family from your messaging today is a roster operation plus an audience operation, not one automatic consequence of the other. It is on the near-term fix list because it is the highest-consequence gap we have, and it is written down here rather than discovered by a family who kept getting attendance calls for a child who left in October.
Ask every vendor you evaluate the same question, in these words: "When a student is withdrawn in tonight's roster file, what stops the message tomorrow?" The answer should name a specific mechanism. Ours, today, is a person.
What you get that is genuinely unusual
Set against that list of gaps, four things in this category are ours alone as far as we can find:
- A public REST API you can read without a login. 28 endpoints, org-scoped, enforced by Postgres row-level security running under a non-owner role that cannot bypass its own policies. The roster endpoint is documented including rate limits and webhook signature verification. No named competitor publishes API documentation on the open web at all.
- An MIT-licensed CLI and MCP server. 16 commands, 19 MCP tools. It runs on your machine, it is not a Kastr-hosted service, and you can read what it sends.
- Connector configs that reject pasted credentials. Paste a string starting
sk_,whsec_,AKIA,AIza,ghp_or-----BEGINinto a roster connector config and it is rejected outright. You store a reference to a secret, not the secret. A rejected paste is the feature. - One identity per human. A parent who is also a bus driver and also a teacher at another building is one person record with three effective-dated roles, not three duplicates. Split households, Skyward's Family 1 / Family 2 and staff-who-are-also-parents all collapse correctly.
Pricing does not change based on which route you take. $3.50 per student per year under 5,000 students, $3.25 to 14,999, $3.00 above. Roster sync is not an add-on module, and there is no integration fee. The whole price list is public.
Questions people actually ask
Does Kastr have a native PowerSchool or Infinite Campus connector?
No. No Kastr code authenticates to any SIS or pulls records from one. Your district produces an export — which in most cases already exists for another vendor — and a scheduled job POSTs it to our roster endpoint. Districts running Clever or ClassLink can use that broker's OneRoster output instead of building a new extract.
If there is no native connector, what does the district actually have to build?
Usually one cron line. The SIS export normally exists already and drops to an SFTP location you control. What you add is a scheduled call to the MIT-licensed Kastr CLI, or a curl POST, pointing at that file. Budget four to eight hours of one engineer's time for a first clean dry run on a mainstream SIS, most of it spent on field mapping rather than plumbing.
Which systems can give Kastr guardian phone numbers, and which only give email?
The mainstream student information systems all carry guardian phone numbers and can export them. The gap is at the broker tier: a Clever rostering feed frequently arrives without shareable guardian contact fields, because sharing them is a per-district and per-application decision that is often left off. Google Workspace and Microsoft 365 give you staff only. Canvas, Schoology and Google Classroom give you opt-in guardian email at best, which is not a roster.
Does Kastr write anything back to our SIS?
No. There is no write-back of any kind — no attendance, no message logs, no contact corrections, no grades. Data flows one direction. If a guardian tells us their number changed, that correction lives in Kastr and your SIS remains the system of record until someone updates it there.
Who owns the nightly sync job, the district or Kastr?
The district. The job runs on your infrastructure, on your schedule, with an API key you generated and can revoke. We do not hold credentials to your systems and cannot reach into them. The trade is that if the job stops, it stops on your side — so point your existing monitoring at it the same way you would any other overnight batch.
Do we pay extra for roster integration?
No. There is one price per student per year, every feature included, no integration fee, no per-connector charge and no per-message fee. The API, the CLI, the webhooks and the roster endpoint are part of the product rather than an enterprise tier.
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.