How to sync Infinite Campus with Kastr
Infinite Campus models households, relationships and a stack of per-relationship checkboxes that most communication tools flatten into a single guardian field. Flattening them is how a district ends up messaging an adult a court order says should not be contacted. This page is the flag-by-flag map, plus the two export routes and what each one can actually reach.
| Campus flag on the relationship | What it means in Campus | Kastr result | Receives a broadcast? |
|---|---|---|---|
| Guardian | Educational-rights adult for this student | Guardian edge created, rank from contact sequence | Yes |
| Mailing | Receives district correspondence | consentState set to allow general correspondence | Yes |
| Guardian, not Mailing | Has rights, opted out of routine mail | Edge created; correspondence consent withheld | Emergency only |
| Mailing, not Guardian | Grandparent, stepparent, no legal rights | Edge created at lower rank, marked non-guardian | Yes, routine only |
| Portal | Has a Campus Portal account | Recorded, otherwise ignored | Irrelevant — no Kastr account needed |
| Messenger preference (voice / text / email) | Per-channel opt-in held in Campus | Per-channel consentState on each contact point | Per channel |
| Emergency contact only | Not a guardian, call in emergencies | Contact point marked emergency-scope | Not for routine sends |
| Restricted / no-contact | Court order or district restriction | Edge suppressed at import; nothing created | No |
The row worth arguing about internally is Guardian-but-not-Mailing. We treat it as emergency-eligible and routine-suppressed, because an adult with educational rights should hear about a lockdown regardless of their preference for weekly newsletters. If your district's counsel reads it differently, it is a configuration conversation and not a code change.
Route one: Ad Hoc Reporting on a schedule
Campus Ad Hoc Reporting is the workhorse and the route most districts already know. Build a filter, select the data elements, schedule the export, drop it to storage you control, POST it.
The field paths worth selecting for a roster that will validate on the first attempt:
- Student — state or local student number, legal first and last name, calendar and school, grade level, and the enrolment start and end dates. Not just the current enrolment record: the end date is what tells the diff engine a student left rather than vanished.
- Enrolment — service type, No Show flag, end status. Service type matters in districts that carry partial or shared-time enrolments; those students are real and their families expect messages.
- Relationship — the person on the other end, the relationship description, the sequence number, and every flag in the table above.
- Contact — household phone, cell phone, work phone, email, and the per-number messenger preferences. Export the number type; a cell number and a household landline are not interchangeable and Kastr will not guess.
- Language — the guardian's home or preferred language, not the student's. This drives translation, and getting it from the student record is a common and quietly damaging mistake in multilingual districts.
One flat file per night with a row per student-guardian pair is entirely acceptable. Kastr does not require a OneRoster bundle, though it will happily take one.
Route two: the Campus OneRoster API
Campus exposes OneRoster through Digital Learning Applications Configuration, which is how it feeds most edtech applications. If your district has that configured, it is less work to reuse than to build a new Ad Hoc export.
The trade-off is coverage. OneRoster's centre of gravity is students, staff, sections and enrolments — the things a learning application needs. Guardian contact detail is the weakest part of the standard and the least consistently populated in real implementations. A OneRoster feed that gives you a perfect class roster and no guardian mobile numbers is a perfect class roster and a useless communications roster.
The pragmatic answer, and the one we recommend for Campus districts: take students, staff, schools and enrolments from OneRoster if you already have it, and take guardians and contact points from a small purpose-built Ad Hoc export. Two files, one POST, no argument with the standard. The OneRoster field map sets out exactly which files Kastr reads and which it ignores.
No Show students and the rollover-night abort
Campus No Show is the flag for a student who enrolled and never arrived. In August they are a legitimate audience — those are exactly the families somebody in the front office needs to reach. After the No Show process runs and enrolments are end-dated, they become withdrawals.
That produces a predictable spike. Combine it with the other rollover-week activity — end-dating an entire graduating cohort, closing out last year's calendar, activating next year's enrolments — and you get a night where a naive export legitimately contains a fraction of your district.
The guardrail is the safety net, not the plan. A run that would withdraw more than 50% of active records aborts as aborted_guardrail and writes nothing. That protects you from the catastrophic version. The 30%-withdrawal version passes the guardrail and is still wrong, which is why the dry run exists: read the ledger during rollover week before you let the job go back to automatic.
Practical rule for Campus districts: suspend the nightly POST from the day you begin calendar rollover until the day after enrolments activate. Run it by hand, with --dry-run, once per day during that window.
Households, and the identity problem Campus makes visible
Work through a real case. Student A lives between two households. Household 1 contains mother and stepfather. Household 2 contains father and stepmother. The stepmother also teaches at the high school in your district. That is one student, four adults, five relationship rows, and one adult who appears in a completely different part of your data as staff.
Most communication platforms produce five records and text the stepmother twice, once as a guardian and once as staff. Kastr stores four people. The stepmother is one person carrying two effective-dated roles: guardian of Student A from the date the relationship began, and teacher at the high school from her hire date. A broadcast to all staff and a broadcast to Student A's guardians reach her once each, and a broadcast that happens to include both reaches her once in total.
Retention follows the role rather than the record, so student personally identifiable information and guardian records are held under different retention classes derived at creation. Guardians never need a Campus Portal account, or any account, to receive messages — Kastr sends to phone numbers and email addresses, and the only login that exists anywhere in the product is a 15-minute single-use magic link.
Questions people actually ask
Does Kastr connect to Infinite Campus through the OneRoster API or an Ad Hoc export?
Either, and in practice a hybrid is best. Campus's OneRoster output covers students, staff, sections and enrolments well but guardian contact coverage is thin. Most districts take those entities from OneRoster if it is already configured, and add a small Ad Hoc export for relationships and contact points. Neither route involves Kastr logging into Campus; you push, we never pull.
How does Kastr treat a Campus relationship marked Guardian but not Mailing?
The guardian edge is created, so the relationship and its rights are recorded, but routine correspondence consent is withheld. That adult receives emergency-flagged messages and not the weekly newsletter. The reasoning is that an educational-rights adult should hear about a lockdown regardless of a mail preference. It is configurable if your district reads it differently.
What happens to Campus No Show students on the first sync of the year?
Before the No Show process runs they are active enrolments and are messageable, which is usually what you want in August. Once they are end-dated they classify as withdrawals in the next diff. If that coincides with cohort end-dating and calendar rollover, the combined withdrawal volume can cross the 50% guardrail and abort the run — which is the correct outcome. Run rollover week by hand with dry runs.
Does a parent need a Campus Portal account to receive Kastr messages?
No. Kastr sends to phone numbers and email addresses taken from the roster. The Portal flag is recorded and otherwise ignored. There is no Kastr account for guardians to create; if they open the family web view, they do it through a single-use magic link that expires in fifteen minutes.
Can one person exist once in Kastr if Campus has them in two households and on staff?
Yes, that is the core of the identity model. One person record carries many effective-dated roles — guardian in two households and teacher at a third building are three roles on one human. Broadcasts de-duplicate across roles, so an all-staff message and a guardian message never arrive twice for the same reason.
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.