Kastr integrations: how your student and guardian data actually gets in

Kastr can read OneRoster 1.1 and 1.2 REST rosters and preview uploaded OneRoster CSV ZIP files. An organisation administrator configures the connection under Integrations, OneRoster. REST sync can run nightly after the first manual apply when the production worker is configured for that organisation. The custom JSON roster API and typed roster CSV import remain separate routes. A standards-based connection does not establish a vendor partnership or certification.

Last reviewed 2026-08-04

How each system gets roster data to Kastr, and what arrives with it
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

Export availability and guardian coverage depend on the provider, version, licensing and district sharing settings. Kastr can read the documented OneRoster subset directly by REST or manual CSV ZIP upload. Other export formats need the typed CSV import or a district-maintained JSON API job. The estimates above are not validated delivery commitments.

Read this first: what Kastr does not have

Standards-based roster connection. Kastr reads supported OneRoster REST endpoints and CSV ZIP exports directly. This is different from a proprietary PowerSchool plugin, Infinite Campus app or Aeries connector, and does not establish a vendor partnership.

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 or route targeting. An audience resolves as the district, a school, a class, specific people or a saved group. There is no grade, bus route or site targeting, so 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

Choose the route first, because input formats, preview and withdrawal behaviour differ:

Choose the input route. Use Integrations, OneRoster for supported REST endpoints or full CSV ZIP uploads. Use the Import page for the separate typed Kastr CSV template, or the public roster API for custom JSON entries.
Check the provider feed. A SIS or broker can supply the OneRoster endpoint or export. Confirm authorisation, guardian users, agent links, contact fields and the selected schools before applying.
Use a custom job only when needed. For an unsupported export format, your job can map records to POST /api/v1/roster/sync. That endpoint has different preview and withdrawal behaviour from the native OneRoster connection.
Review the correct workflow. The custom JSON API applies posted entries immediately and uses an HTTP 409 withdrawal guard. Native OneRoster manual syncs use preview/apply; scheduled REST runs apply automatically and can be held for approval. The typed CSV import has different omission rules.

The reason to describe it this plainly is that it is auditable. You can watch the batch leave your network, read the ledger, and reconcile the counts against your own SIS before a single message goes anywhere.

Custom JSON API example, not native OneRoster

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

Withdrawal behaviour depends on the route. Native OneRoster ends managed roles and enrolments absent from a read marked complete; it retains person records. The separate JSON roster API and typed CSV import have their own withdrawal and omission rules. Do not infer that a OneRoster omission globally retires the person or removes every other role.

The typed CSV import leaves missing rows unchanged and uses explicit withdrawal rows. OneRoster CSV is a snapshot path and can withdraw by omission after approval. Review the resulting roles and audiences for the actual school rather than assuming all input formats behave alike.

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 is the send-time filter: retired and suppressed people are dropped when the audience resolves.

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.
Credential handling depends on the interface. Generic source configuration rejects credential-shaped literals. The dedicated OneRoster REST form accepts the provider secret and encrypts it with AES-256-GCM.
Source-linked identity matching. Native OneRoster can adopt existing records using source identifiers or unambiguous organisation email matches. Incoming adult duplicates merge only under the documented name-and-email rule. Shared addresses and changed IDs need review.

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?

If there is no native connector, what does the district actually have to build?

First check whether the district can provide a supported OneRoster REST endpoint or CSV ZIP export. A custom transformation job is needed only for another input format or additional mapping requirements. Validate a representative roster before estimating implementation effort.

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 marked-up 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 or add-on modules. Normal messaging is included under a published fair-use allowance, with transparent cost recovery only above it.

See the pricing table Talk to Kastr