How to sync Alma SIS with Kastr

Hours are one person's engineering time to a clean first sync, 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, your job needs the same five things to build Kastr's roster entries. 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 student entry. 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 guardian entry linked to the student with guardianOfSourceId. The entry carries no relationship type or rank, so the relationship decides who goes in. This is the part that determines who actually receives an urgent message, and it is the part worth spending your review time on.
• Enrolments → who is in the batch. A student whose enrolment has ended is left out, and the next sync withdraws them.
• Sections → not part of a roster entry. For targeting, Kastr's audiences are the district, a school, a class, specific people and saved groups; there is no grade or route audience.
• Contact points → the entry's phone and email fields, plus languagePref. There is no phone-type field, so use Alma's phone type to send the mobile rather than a landline.

Credentials depend on the route. A proprietary Alma API job keeps its credentials in the district secret store. The dedicated Kastr OneRoster REST connection instead stores its supplied client secret encrypted with AES-256-GCM. Generic roster-source configuration and native OneRoster connection settings are different interfaces.

For native OneRoster ingestion, use the OneRoster connection guide. For a proprietary API job, use the separate JSON roster API contract. The two paths do not share the same payload or preview semantics.

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 needs a different channel. Kastr has no voice channel, so a household reachable only by landline cannot be reached through Kastr at all; that call has to come from your phone or emergency notification system. Export the phone type so your job does not send a landline as though it were a mobile.
• Retries only help if the number is good. Kastr retries a failed delivery and records the delivery receipt, but a retry 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. The batch your job builds gives you that list: the students with no guardian phone or email in it. 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, turns it into JSON entries and POSTs them to POST /api/v1/roster/sync with plain curl or any HTTP client; the Kastr CLI's roster command only runs a demo sync. 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.

The custom JSON roster API has no dry-run mode, so check the first batch by hand before you send it. The diff engine hashes each record payload with SHA-256, compares it against the stored hash, and classifies adds, changes, unchanged records and withdrawals. A first run on a 3,000-student district typically adds every record, a second run finds almost everything unchanged, and a third run finds a handful of genuine changes. If night three still finds 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 batch would withdraw more than half of active records, the run aborts with an HTTP 409, records 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 building the first batch and checking it before the first POST; 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

Related