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 Kastr does | Contact rank |
|---|---|---|---|
| Single family unit, two adults | Two guardian records | Two people, two guardian edges | Skyward guardian order |
| Family 1 and Family 2, different adults | Two families, sometimes only Family 1 imported | All four adults, all four edges, both households retained | Family 1 adults rank above Family 2 by default |
| Same adult in Family 1 of sibling A and Family 2 of sibling B | Two copies of the adult; two of every message | One person, two guardian edges | Ranked per student, not per person |
| Adult who is also a district employee | A guardian record and a staff record | One person, effective-dated guardian and staff roles | Unaffected |
| Emergency contact, not a guardian | Imported as a guardian or dropped | Contact point marked emergency-scope, no guardian rights | Below all guardians |
| Court-ordered no-contact adult | Frequently imported anyway | Edge suppressed at import; nothing is created to forget later | n/a |
| Guardian with a mailing address only, no phone | Counted as reachable | Person exists, zero reachable contact points, visible as such | n/a |
The default that Family 1 outranks Family 2 is a starting position, not a judgement about your families. It is set per district and can be inverted or flattened. What is not configurable is the de-duplication: the same human is never stored twice, because two copies means two texts and two bills for the same message.
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. The newer platform, with a genuine API and a OneRoster output. If you are on Qmlativ, use it: the entity model is cleaner, the scheduling is better, and the OneRoster feed covers students, staff and sections without hand-built field lists. You will still want a small supplementary extract for guardian phone numbers, because OneRoster's guardian coverage is the weak part of the standard rather than a Skyward failing.
Both land in the same place. A district-side cron job calls the MIT-licensed Kastr CLI or plain curl and POSTs the file to /api/v1/roster/sync. Run it with --dry-run until three counts reconcile: total students, total guardians, and students with at least one reachable phone number. The third number is the one that predicts whether your first real broadcast works.
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 establishes the guardian edge.
- 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. Becomes
consentStateon the resulting contact points. - Emergency contact — call in an emergency, no routine sends, no guardian rights.
- Restricted or no-contact — the one that matters most.
Restricted adults are suppressed at import, not filtered at send. If Skyward marks an adult as restricted or no-contact, Kastr does not create a guardian edge or a contact point for them at all. 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 during the dry run. Pull three restricted adults from Skyward by name and confirm they are absent from the ledger. It takes five minutes and it is the single most consequential check in the whole onboarding.
Every contact point carries a validationState, a consentState, a source and a rank. The source is what stops a 2016 landline from outranking the mobile number a parent supplied last month.
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.
- Dry-run the first Qmlativ file against the existing roster. If the ledger shows adds and withdrawals in roughly equal numbers, your identifier changed. Stop.
- 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 file, and if the identifiers hold, the first Qmlativ dry run should show 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?
Yes, because Kastr does not connect to either one. Both products can produce a scheduled export — Data Mining in SMS 2.0, the API or OneRoster output in Qmlativ — and a district-side job POSTs that file to the roster endpoint. Qmlativ is less work because its OneRoster output covers students, staff and sections without hand-built field lists.
How does Kastr handle Skyward Family 1 and Family 2 for a student in two households?
Both households are retained and all their adults become guardian edges on the student. Family 1 adults rank above Family 2 by default, which is a configurable starting position. Crucially, an adult who appears in Family 1 for one sibling and Family 2 for another is one person with two edges, not two people — so they receive one message rather than 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 an API; it requires a file with students, guardians, the relationship between them, and contact points with their types.
What happens to a Skyward contact marked as no-contact or restricted?
Nothing is created. The guardian edge and contact points are suppressed at import rather than filtered at send time, so there is no record in Kastr that a bulk operation could later include by accident. Verify it yourself during the dry run by checking three known restricted adults against the ledger.
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. Dry-run the first Qmlativ file against the live roster and check that adds and withdrawals are not suspiciously symmetrical.
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.