How to sync Alma SIS with Kastr
There is no Alma connector, no partnership and no certificate flow. Alma is unusually pleasant to work with anyway, because it exposes both a modern REST API and OneRoster output, and a small district can get to a clean dry run in an afternoon. This page is the endpoint map, the two routes, and an honest hour estimate for a district with nobody whose job title contains the word integration.
| Route | First-sync effort | Ongoing upkeep | Scheduling | Best for | Main drawback |
|---|---|---|---|---|---|
| REST API pull | 4–6 hours | Low once written | You schedule it | Districts with any scripting capability | Someone has to own a script |
| OneRoster output | 2–4 hours | Very low | You schedule the fetch | Districts already consuming OneRoster elsewhere | Guardian contact coverage depends on your configuration |
| CSV export, hand-driven | 1–2 hours | High — a person every time | Manual | A first pilot, or a school under 500 students | Somebody forgets in week three |
Hours are one person's engineering time to a clean dry run, not elapsed days, and they assume you can already produce an export from Alma. Start on the CSV route to see your data land, then move to whichever automated route you will actually maintain. A pilot that runs on a manual export for a term is a legitimate answer; a production roster that depends on someone remembering on a Friday is not.
The endpoint and field map
Whichever route you take, Kastr wants the same five things. In Alma's REST API they map roughly as follows — confirm the exact resource names against the API documentation for your instance, because Alma iterates and we will not pretend to a version guarantee we cannot hold.
- Students → a Kastr person with a student role. Carry a stable identifier and never change it: the diff engine matches on it, and swapping identifiers converts your whole enrolment into a withdrawal followed by an addition.
- Guardians and relationships → a Kastr person plus a guardian edge to the student, carrying the relationship type and a rank. This is the part that determines who actually receives an emergency message, and it is the part worth spending your review time on.
- Enrolments → effective-dated role rows and the school the record belongs to in the organisation hierarchy.
- Sections → stored, and useful later. Be aware that Kastr's audience resolver does not currently segment on section or school; today an audience is everyone or an explicitly selected set of people.
- Contact points → phone and email rows carrying type, a validation state and a consent state. Phone type is what separates an SMS-capable number from a voice-only one, so export it rather than inferring it.
Tokens. Whatever credential Alma issues, it goes in your secret store, not in a Kastr connector config. Kastr's roster connector configs hard-reject literal credentials — paste something beginning sk_, whsec_, AKIA, AIza, ghp_ or -----BEGIN and it is refused outright. You store a reference. The rejection is the feature, and it exists because the alternative is a credential sitting in a vendor's database forever.
The field map is the same one documented at the OneRoster page and the plain CSV spec. Nothing about Alma changes the destination.
Guardians with email and no mobile number
This is the finding that matters more than anything else on this page, and it is not an Alma defect — every SIS has it. Some proportion of your guardian records hold an email address and no mobile number, or a landline recorded without a type so it looks like a mobile.
The consequences are specific:
- No mobile means no SMS. That family is email-only, and email open rates during a weather closure are not what a district would like them to be.
- A landline is not useless. Kastr sends voice as well as SMS, and a voice call to a landline reaches a household that a text does not. Export the phone type so the platform can tell the difference rather than guessing.
- SMS to voice failover only helps if a voice number exists. Kastr fails a terminally failed SMS over to voice, with the failover recorded against the original attempt. That mechanism is worth nothing for a family with one bad mobile and no second contact point.
- Count the zero-contact students before you sign anything. Students with no reachable contact point at all. In most districts it is one to four per cent, and nobody knows the number until somebody counts it. Kastr's dry run gives you that list. Hand it to the office; it is the most valuable output of the whole exercise, with any vendor.
Fix it in Alma, not in Kastr. There is no write-back of any kind, so a correction made downstream is a correction that will be overwritten by tonight's file.
Standing up the nightly job, and what a small district actually spends
The mechanism is deliberately unremarkable. A scheduled job on a district machine produces or fetches the export and POSTs it to POST /api/v1/roster/sync, using the MIT-licensed Kastr CLI or plain curl. The job runs on your infrastructure with a key you generated and can revoke. We hold no credentials to your systems and cannot reach into them.
Run the first three nights with --dry-run. The diff engine hashes each record payload with SHA-256, compares it against the stored hash, and returns a ledger of adds, changes, unchanged records and withdrawals without writing anything. Read the ledger. A first run on a 3,000-student district typically shows every record as an add, a second run shows almost everything unchanged, and a third run shows a handful of genuine changes. If night three still shows thousands of changes, something in your export is non-deterministic — usually a timestamp or a re-ordered contact list riding along in the payload.
The guardrail is not optional and cannot be tuned away casually: if accepting a file would withdraw more than half of active records, the run aborts with aborted_guardrail and writes nothing. That defends the failure this category is famous for, where a truncated export parses cleanly and quietly unenrols a district overnight.
Realistic time for a district with no integration engineer, broken down honestly: two to three hours getting the first export out of Alma and understanding which fields carry the guardian relationship; one hour on a manual POST and reading the first dry-run ledger; one to two hours reconciling counts against Alma — active students, student-guardian pairs, distinct guardians, students with an SMS-capable number, students with none; one hour scheduling it and pointing your existing monitoring at it. Call it a working day spread over a fortnight. The part that overruns is always the guardian relationship review, because that is where you find out what your data actually says.
Pricing does not change with the route: $3.50 per student per year under 5,000 students, $3.25 to 14,999, $3.00 above, everything included, no integration fee. The whole price list is public.
Questions people actually ask
Is the Alma REST API or its OneRoster export the easier path?
OneRoster is less work if your district already consumes it elsewhere, because the shape matches what Kastr expects and there is less mapping to think about. The REST API is better if you want fine control over which guardian fields come across, or if your OneRoster configuration does not include guardian contact detail. Both land at the same endpoint. Start with a manual CSV to see your data arrive, then automate whichever route you will genuinely maintain.
What if Alma has guardian email addresses but no mobile numbers?
Those families are email-only, which is a real reach problem during a closure. Export the phone type so a landline is recognised as voice-capable rather than treated as a failed SMS target, since Kastr sends voice as well as text. Then run the dry run and count the students with no reachable contact point at all — usually one to four per cent — and hand that list to the office. Corrections belong in Alma; Kastr never writes back.
How long does a first Alma sync take for a 3,000-student district?
About a working day of one person's time, spread over a fortnight. Two to three hours to get the export out and understand the guardian relationship fields, an hour on the first manual POST and dry-run ledger, one to two hours reconciling five counts against Alma, and an hour to schedule it and add monitoring. The guardian relationship review is what overruns, every time.
Does Kastr require a Kastr-side engineer to set this up?
No, and there is nothing for us to do. The job runs on your infrastructure, on your schedule, with an API key you generated and can revoke, using an MIT-licensed CLI you can read. We hold no credentials to Alma and cannot reach into it. The trade is that if the job stops, it stops on your side, so point your existing overnight-batch monitoring at it.
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.