How to sync Skyward with Kastr
Skyward districts have one rostering problem that everybody else's documentation ignores: Family 1 and Family 2. A student belongs to two family units, an adult can appear in the Family 1 of one sibling and the Family 2 of another, and most communication platforms respond by creating two of that adult. This page is how the split household resolves, plus the export routes in SMS 2.0 and Qmlativ.
| Skyward situation | What most tools do | What your export should send | Watch for |
|---|---|---|---|
| Single family unit, two adults | Two guardian records | Two guardian entries linked to the student | Adults with neither a phone nor an email |
| Family 1 and Family 2, different adults | Two families, sometimes only Family 1 imported | All four adults as guardian entries, from both households | An export that reads Family 1 only silences the second household |
| Same adult in Family 1 of sibling A and Family 2 of sibling B | Two copies of the adult; two of every message | The same stable identifier for that adult everywhere they appear | Two identifiers for one adult |
| Adult who is also a district employee | A guardian record and a staff record | A guardian entry, plus a teacher entry if they teach, each with a stable identifier | Identifiers that change between runs |
| Emergency contact, not a guardian | Imported as a guardian or dropped | Nothing; a roster entry has no emergency-only setting | Emergency contacts exported as guardians |
| Court-ordered no-contact adult | Frequently imported anyway | Nothing; Kastr cannot see the restriction, so the export is where it is enforced | Check three known restricted adults before the first sync |
| Guardian with a mailing address only, no phone | Counted as reachable | A guardian entry with an email if there is one; with neither, it reaches nobody | Count these before you rely on the roster |
A roster entry has no rank, so Family 1 and Family 2 adults arrive as equals; if your district wants one household treated differently, that decision is made in the export. What matters most is that each adult keeps one stable identifier wherever they appear, because the diff engine matches on it.
SMS 2.0 or Qmlativ: two products, two export stories
Skyward SMS 2.0. The export tool is Data Mining, occasionally with Report Designer for layout. Build a student data-mining report with the family and guardian objects attached, schedule it, deliver it to an SFTP path you control. It is more clicking than a modern API and it works fine. Most SMS 2.0 districts already run one of these for a state report and can copy the pattern.
Skyward Qmlativ. If your installation provides a supported OneRoster endpoint or CSV export, evaluate it with the native OneRoster connection. Confirm guardian data and authorisation with the provider. A separate contacts export is not automatically merged by Kastr.
Use the native OneRoster connection for a supported endpoint or CSV ZIP. Use a custom mapping job for a proprietary export. Review student, guardian and reachable-contact counts before applying or posting, using the safeguards of the selected route.
The guardian flags, and the one that must not be ignored
Skyward carries several indicators per guardian, and they do not mean the same thing:
- Legal guardian, educational rights. This decides whether the adult is exported as a guardian.
- Lives with, residence, not rights. Useful for ranking, meaningless for permission. An adult can live with a student and hold no rights, and the reverse is just as common.
- Mailing / correspondence, whether routine district mail goes to them. A roster entry has no consent field, so this decides whether the adult belongs in the export at all.
- Emergency contact, call in an emergency, no routine sends, no guardian rights.
- Restricted or no-contact, the one that matters most.
Restricted adults belong out of the export, not filtered later. Kastr cannot see Skyward's restriction flag, so if Skyward marks an adult as restricted or no-contact, your export has to leave them out entirely. Then there is nothing in the system to accidentally include in an audience later, nothing to un-tick, and nothing that a bulk operation can resurrect. A record that does not exist cannot be messaged by mistake.
Verify this on your own data before the first sync. Pull three restricted adults from Skyward by name and confirm they are absent from the batch your job builds. It takes five minutes and it is the single most consequential check in the whole onboarding.
Contact-point records store the value, validation state, consent state, source and rank. SMS delivery checks consent for the selected number and honours opt-outs. A source label does not automatically replace the primary phone number or change delivery priority.
Mid-migration districts: SMS 2.0 to Qmlativ
A large number of Skyward districts are somewhere between the two products, and the cutover is a guardrail-abort candidate for a mundane reason: student identifiers frequently change shape.
The diff engine matches on the external identifier you send. If Monday's file identifies a student as 0012345 and Tuesday's identifies the same student as 12345, that is not one student with a changed record. It is one withdrawal and one addition, repeated across your entire enrolment. The run either aborts on the guardrail or, worse, squeaks under it and produces a roster of strangers.
Three things prevent it:
- Decide the identifier before cutover and pad or strip consistently on both sides. Leading zeros are the usual culprit, and a spreadsheet in the middle of the process is usually where they get eaten.
- Compare identifiers before the first Qmlativ sync. Match a sample of students in the first Qmlativ export against the last SMS 2.0 export. If the same students carry different identifiers, stop and fix the export.
- Do not run both feeds on the same night. Two sources posting to one endpoint alternate withdrawal states and produce a genuinely confusing audit trail.
To answer the obvious question: the SMS 2.0 to Qmlativ move does not require re-onboarding Kastr. It is a change of source for the same roster, and if the identifiers hold, the first Qmlativ sync should produce a handful of changes and nothing else.
What this costs and what it does not include
Roster sync is not a module and there is no integration fee. One price per student per year, every feature, no tiers, $3.50 under 5,000 students, $3.25 to 14,999, $3.00 above, fixed for 36 months.
What Skyward districts should know we do not do: there is no Skyward partnership, no certified connector, no Family Access single sign-on, no write-back of any kind, and no automated attendance notices, rules configure in the interface but no engine fires them yet. Guardians never sign in to anything; messages arrive on the phone number and email address the roster supplied.
Every sync run, including aborted ones, is recorded in a per-organisation append-only audit log whose entries are chained with SHA-256, so the question "what did the roster look like on the day of the incident" has an answer that nobody can edit after the fact.
Questions people actually ask
Does Kastr work with both Skyward SMS 2.0 and Qmlativ?
For either product, confirm the export or endpoint available to your district. Kastr can consume the documented OneRoster subset directly; a proprietary report needs mapping to the typed CSV template or custom JSON API. This is not a claim of tested compatibility with every Skyward configuration.
How should our export handle Skyward Family 1 and Family 2 for a student in two households?
Send the adults from both households as guardian entries for the student; an export that reads Family 1 only is how the second household goes silent. A roster entry has no rank, so both households arrive as equals. Give an adult who appears in Family 1 for one sibling and Family 2 for another the same stable identifier in both places, not two.
Can I build the roster export in Skyward Data Mining rather than using an API?
Yes, and for SMS 2.0 districts it is the normal route. A scheduled Data Mining report with the family and guardian objects attached, delivered to SFTP, is a completely valid roster source. Kastr does not require OneRoster format or a Skyward API. What it takes is JSON entries built from that report (students and guardians, each guardian linked to a student, with the phone, email and language to use), or the same data as a CSV on the Import page.
What should happen to a Skyward contact marked as no-contact or restricted?
They should never reach Kastr. Kastr cannot see Skyward's restriction flag, so your export has to leave that adult out, and then there is no record in Kastr that a bulk operation could later include by accident. Before the first sync, check three known restricted adults against the batch your job builds.
Does our Skyward-to-Qmlativ migration require a Kastr re-onboarding?
No, but it needs one careful night. The risk is that student identifiers change shape between products, leading zeros being the usual offender, which the diff engine reads as a mass withdrawal plus a mass addition. Before the first Qmlativ sync, match a sample of its identifiers against the current ones, and fix the export if they differ.
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.