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 what your export should do with each flag, plus the two export routes and what each one can actually reach.
| Campus flag on the relationship | What it means in Campus | What your export should do | Should they receive a broadcast? |
|---|---|---|---|
| Guardian | Educational-rights adult for this student | Send as a guardian entry linked to the student | Yes |
| Mailing | Receives district correspondence | Include the adult; a roster entry has no consent field | Yes |
| Guardian, not Mailing | Has rights, opted out of routine mail | Include or leave out, one rule for the whole district; a roster entry has no urgent-only setting | District choice |
| Mailing, not Guardian | Grandparent, stepparent, no legal rights | Include only if your district wants them messaged; a roster entry has no non-guardian marker | District choice |
| Portal | Has a Campus Portal account | Nothing to export | Irrelevant, no Kastr account needed |
| Messenger preference (voice / text / email) | Per-channel opt-in held in Campus | Leave out the mobile number of anyone who has not opted in to texts; Kastr also applies SMS consent and opt-outs to every text | Per channel |
| Emergency contact only | Not a guardian, call in emergencies | Leave out; a roster entry has no emergency-only setting | Not for routine sends |
| Restricted / no-contact | Court order or district restriction | Leave out entirely; Kastr cannot see the flag | No |
The row worth arguing about internally is Guardian-but-not-Mailing. The case for including that adult is that someone with educational rights should hear about an early dismissal or closure regardless of their preference for weekly newsletters; the case against is their stated preference. A roster entry cannot say "urgent only", so the answer is binary and it is your district's: settle it with counsel before the first sync and apply it in the export.
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, then have a job reshape it into JSON entries and POST them.
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 your job a student has left, so it drops them from the batch, which is how the API sync records a withdrawal. On a CSV import, mark the row withdrawn instead.
- 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 so your job sends the cell number; a cell number and a household landline are not interchangeable, and a roster entry has one phone field.
- 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.
A district-maintained flat-file integration remains possible, but it is not the only route. Kastr also reads the documented OneRoster REST and CSV subset directly on Integrations, OneRoster.
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.
Inspect the actual OneRoster feed for guardian users, agent links and contact fields before choosing a route. Kastr does not automatically merge a supplementary Campus contacts export into a OneRoster snapshot. Any enrichment needs an explicit mapping and source-ownership plan.
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.
Withdrawal thresholds are a backstop. Native OneRoster sync offers preview/apply and its managed-role/enrolment approval hold; the separate JSON API uses aborted_guardrail. Neither threshold proves that a roster is complete. Check rollover counts and the documented limitations before enabling automatic runs.
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 once per day during that window, checking the counts before each send.
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?
Kastr can read a compatible, authorised OneRoster REST endpoint directly or accept a OneRoster CSV ZIP. A proprietary Ad Hoc export needs the separate typed CSV or JSON API route. Verify guardian coverage on your district feed; this is not evidence of tested compatibility with every Campus configuration.
What should our export do with a Campus relationship marked Guardian but not Mailing?
Decide once, with counsel, and apply it in the export. A roster entry has no urgent-only setting, so that adult is either in the export and reachable by any send whose audience includes them, or left out and reachable by nothing. The case for including them is that an educational-rights adult should hear about an early dismissal or closure regardless of a mail preference.
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 and check the counts before each send.
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 does not need to be in the export. 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 or add-on modules. Normal messaging is included under a published fair-use allowance, with transparent cost recovery only above it.