How to sync Ed-Fi ODS/API data with Kastr
Kastr does not consume the Ed-Fi API. A district-side job queries your ODS, shapes the resources into a roster file, and POSTs it. That is more work than the other routes in this cluster — ten to twenty engineering hours — and it is the right route for districts whose ODS is already the canonical operational data source.
| Ed-Fi resource | Pull | Kastr destination | Notes |
|---|---|---|---|
educationOrganizations / schools | Yes | Organisation hierarchy | The LEA becomes the root; schools become children |
students | Yes | Person records, student role | Take the unique student identifier, not the resource id |
studentSchoolAssociations | Yes | Effective-dated enrolment | Entry and exit dates drive add and withdraw classification |
studentEducationOrganizationAssociations | Yes | Contact points, language | Holds electronicMails, telephones, addresses, language descriptors |
contacts (DS5) / parents (DS4) | Yes | Guardian person records | Renamed in Data Standard 5 — version-detect before you write the extract |
studentContactAssociations (DS5) | Yes | Guardian edges, rank | Was studentParentAssociations in DS4 |
staffs | Yes | Person records, staff role | Only if you want staff messaging from the ODS |
staffEducationOrganizationAssignmentAssociations | Yes | Effective-dated staff roles | Gives you a real start and end date per assignment |
sections, studentSectionAssociations | Optional | Stored, not yet an audience filter | Skip on a first pass |
studentSpecialEducationProgramAssociations and similar | Do not pull | — | Programme participation is not needed to send a message |
The last row is a position, not an oversight. Pulling special-education, homelessness or free-and-reduced-price-meal programme associations into a communications platform acquires a category of sensitivity in exchange for capability the platform does not have. If a future targeted-outreach feature needs it, that is a conversation with its own consent design, not a quiet addition to a nightly job.
Data Standard 4 to 5: the rename that breaks nightly jobs
Data Standard 5 renamed the guardian half of the model. What was parents is now contacts. What was studentParentAssociations is now studentContactAssociations. The change is sensible — a great many adults responsible for a student are not parents — and it silently breaks any extract that hard-codes the old paths.
Because ODS upgrades are frequently scheduled by someone other than the person who wrote the extract, put a version-detection step at the top of the job rather than trusting a calendar. Query the API's version metadata, branch on the result, and log which branch ran. Six lines of code that save a fortnight of confusion.
The failure mode if you do not: the job runs, the student half succeeds, the contact half 404s, and you POST a file with students and no guardians. Depending on how your extract handles that, either the run fails validation or you produce a roster where nobody can be reached. The dry run will show it immediately as a collapse in guardian count, which is another reason to read the ledger rather than the exit code.
Descriptors, and where the mapping file lives
Ed-Fi expresses controlled vocabulary as descriptor URIs, and their values are set by the standard, by your state, and by your district in layers. A contact-priority descriptor from Texas does not look like one from Indiana.
The mapping between descriptors and Kastr's fields therefore belongs in your extract job, not inside Kastr. Three mappings you need:
- Relation descriptor → the relationship label on the guardian edge, and whether that adult counts as a guardian at all. Mother, father and guardian obviously do. Neighbour and employer obviously do not. The middle of that list is a district decision.
- Contact priority → contact rank. Ed-Fi gives you an explicit priority integer on the association, which is cleaner than most SIS models.
- Electronic mail type and telephone number type → channel capability. A mobile telephone type becomes an SMS-capable contact point; home and work become voice-only. Getting this wrong is how a district texts a workplace switchboard for a year.
Keeping the mapping on your side means you can change it without a release from us, and it means the mapping is reviewable in your own version control alongside the job that uses it.
Authentication, and which ODS to point at
Ed-Fi uses OAuth2 client credentials: your job exchanges a key and secret for a short-lived token and presents it as a bearer token. Standard, uninteresting, and the only thing worth saying about it is where the secret lives.
Store the client secret in your secret manager. Kastr never needs it and cannot use it. On our side you hold an API key, SHA-256 hashed at rest and displayed exactly once. And if anyone tries to paste a credential-shaped string into a Kastr roster connector config — anything starting sk_, whsec_, AKIA, AIza, ghp_ or -----BEGIN — the save is rejected. You store a reference, not the secret.
District ODS, not the state ODS. Several state education agencies run Ed-Fi at scale — Texas through TSDS, plus Indiana, Arizona, Nebraska and Michigan among others. The state ODS is a reporting destination: it lags, it is scoped to what the state collects, and guardian contact detail is frequently not part of that collection. For a communications roster you want the district ODS, which is current and complete. Pointing a nightly comms sync at a state reporting environment is a mistake that looks reasonable in a diagram and fails in practice.
Kastr writes nothing back to your ODS. No attendance, no message events, no contact corrections. If you want message history in your Ed-Fi environment or a warehouse alongside it, pull it from our REST API on your own schedule.
Effort, cadence and what you get for it
Budget ten to twenty engineering hours for a first clean dry run — the highest figure in this cluster. The work is not the POST, it is the descriptor mapping and paging through resources for a district-sized ODS. Districts that already have an Ed-Fi extract for another purpose can usually halve it.
What you get in exchange is the cleanest source model available. Ed-Fi carries explicit entry and exit dates on studentSchoolAssociations, explicit contact priority, explicit telephone types and explicit staff assignment dates. Every one of those maps onto something Kastr models properly: effective-dated roles, contact rank, channel capability, and a single identity per human who can be a guardian at one school and staff at another without duplication.
Nightly at 02:00 suits most districts. Twice daily for the first three weeks of the year. If your ODS is written throughout the day by an integration layer rather than by an overnight batch, there is no reason not to run more often — a sync where nothing changed writes nothing, because every record payload is hashed and compared before any write is considered.
Every run, including aborted ones, lands in the per-organisation append-only audit log. Its entries are chained with SHA-256 and the table has neither UPDATE nor DELETE available to the application role, so what the roster looked like on any given night is a question with an answer that cannot be edited afterwards.
Questions people actually ask
Does Kastr consume the Ed-Fi API directly?
No. Kastr never pulls from your ODS. A district-side job authenticates with OAuth2 client credentials, queries the resources it needs, shapes them into a roster file and POSTs that to our endpoint. We hold no Ed-Fi credential and cannot reach your environment.
What changed for guardian data between Ed-Fi Data Standard 4 and 5?
The parents resource became contacts, and studentParentAssociations became studentContactAssociations. An extract with hard-coded DS4 paths will 404 on the guardian half after an upgrade while the student half keeps working, which produces a roster of students nobody can reach. Put a version-detection step at the top of the job.
Should I pull from our district ODS or the state ODS?
The district ODS. The state ODS is a reporting destination — it lags, it is scoped to what the state collects, and guardian contact data is often not collected at all. A communications roster needs current and complete data, which is the district instance by definition.
How are Ed-Fi descriptor URIs turned into contact priority in Kastr?
In your extract job, not inside Kastr. Contact priority maps to contact rank, the relation descriptor decides whether an adult is a guardian and what the relationship is labelled, and the telephone number type decides whether a number is SMS-capable or voice-only. Keeping the mapping on your side means you can change it without waiting for a release from us.
Does Kastr write anything back into the Ed-Fi ODS?
No. There is no write path of any kind. If you want message history alongside your Ed-Fi data, pull it from the Kastr REST API into your warehouse on your own schedule. Kastr is a consumer of roster data and never a writer of 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.