How to sync Aeries SIS with Kastr
Aeries is overwhelmingly Californian, which means an Aeries roster carries a set of contact codes and a language-access context that generic documentation ignores. This page covers the CON table, the STU filters that keep withdrawn students from reappearing, the v5 API certificate model, and the California-specific questions that come up in every procurement conversation.
| Aeries field | Holds | Kastr destination | Effect on sending |
|---|---|---|---|
CON.SQ | Contact sequence within the student | Contact rank on the guardian edge | Determines call order and who the office sees first |
CON.CD | Relationship code (mother, father, guardian, other) | Relationship label on the edge, stored as given | None directly — display and audit only |
CON.ER | Educational rights indicator | Guardian rights on the edge | Gates whether the adult counts as a guardian at all |
CON.MC / mailing indicator | Receives district correspondence | consentState on contact points | Routine sends only; emergency ignores it |
CON.TP / phone fields | Home, work and mobile numbers | Separate contact points with channel capability | Mobile becomes SMS-capable, others voice-only |
CON.EM | Email address | Email contact point, with validationState | Invalid syntax is recorded, not silently dropped |
CON.LG / STU.LF | Correspondence language | Person language preference | Selects the DeepL target language for that family |
CON.RS / restriction flags | Restraining order or contact restriction | Nothing is created | Suppressed at import, not filtered at send |
Aeries field usage varies more between districts than in any other major SIS, because the CON table has been extended locally almost everywhere. Treat the left column as the shape of the question. The mapping file is yours to edit and lives with the export job, not inside Kastr.
Route one: Aeries Query on a schedule
Most Aeries districts already live in Query. A student-and-contacts extract is two queries, or one if you are comfortable with the join, and the shape Kastr wants is a row per student-contact pair.
The filters that matter more than the field list:
- Exclude inactive students.
STU.TGcarries the tag for students who have left, andSTU.DELmarks deleted records. An export that omits both filters will pull years of former students, and every one of them arrives as a new active record in the first sync. The dry run will show it as thousands of adds, which is your signal to stop and fix the query rather than proceed. - Decide about pre-enrolled students deliberately. In August you almost certainly want them. In February you almost certainly do not.
- Filter on school, not on the whole district, if you are staging. A single-school pilot is a legitimate first sync, but be aware that switching from one school to the whole district later looks like a very large number of adds — which is fine — and switching back looks like a mass withdrawal, which will abort.
Schedule the query, land the file on storage the district controls, and have cron POST it to /api/v1/roster/sync. Nothing about that path requires Kastr to hold an Aeries credential, which is the property that makes it easy to get through a security review.
Route two: the Aeries v5 REST API, and where the key lives
Aeries v5 exposes a REST API authenticated with a certificate key. If your team would rather pull than schedule an export, that works: a district-side script requests students and contacts, shapes them, and POSTs the result. Kastr never sees the Aeries key.
Which brings up the thing worth stating plainly, because it is the most common way roster credentials leak:
Kastr connector configs reject literal credentials. Paste a string beginning sk_, whsec_, AKIA, AIza, ghp_, xoxb- or -----BEGIN into a roster connector configuration and the save fails. You store a reference to a secret in your own store, not the secret itself. It is a small piece of code and it exists because the alternative — an Aeries certificate key sitting in a vendor's database and, six months later, in a support ticket — is the failure everyone has seen and nobody plans for.
Store the Aeries key in whatever your district already uses: a cloud secret manager, an encrypted environment file on the job host, a credential vault. The Kastr side needs an API key of ours, which is SHA-256 hashed at rest and displayed exactly once at creation. If you lose it, you rotate it; there is no recovery path, by design.
The California questions
CALPADS. Kastr has no relationship with CALPADS, submits nothing, and reads nothing from it. State reporting stays entirely between your district and Aeries. What CALPADS does affect is your data hygiene: districts that keep clean CALPADS-ready enrolment records tend to have clean roster exports, because the same discipline produces both.
Language access. California districts have concrete expectations around translated communication for parents with limited English proficiency. Kastr translates with DeepL, whose target language set is around thirty languages, and shows the translation in the composer before sending so the person hitting send has actually seen what the family will receive. Being precise about what is not there: no district glossary, so a term of art your district has settled on will not be preserved automatically, and no "see original" footer on the translated message. Both are asked for and neither is built.
TCPA and 10DLC. California layers its own expectations on top of the federal position, and neither is solved by software alone. What the platform does is carry consentState per contact point rather than per person, so a guardian who consented to texts on one number and not another is recorded correctly instead of averaged. See the 10DLC explainer for the registration side, which has a real lead time you need in your project plan.
Reconciling the first sync
Before the nightly job goes automatic, reconcile four numbers between Aeries and the Kastr dry run. If any of them is off by more than a rounding error, the mapping is wrong and it is much cheaper to know now:
- Active students. Should match your Aeries active count exactly. A small overage almost always means the
STU.TGfilter is missing. - Distinct guardians. Expect this to be lower than your raw CON row count, because one adult across three children is one person here. A number equal to the CON count means de-duplication is not happening and your identifiers need looking at.
- Students with at least one SMS-capable number. This is the number that predicts whether your first broadcast works. Districts are routinely surprised by it.
- Students with zero reachable contact points. The list, not the count. Hand it to the front office; it is the most useful artefact the whole exercise produces.
Selecting a student in the composer auto-expands to their guardians, so those four numbers are effectively your reach model. And a current limitation to plan around: audiences resolve as specific named people or as everyone, not by school or grade, so a school-level audience is a preset you save once rather than a filter you choose at send time.
Questions people actually ask
Should I use Aeries Query or the Aeries v5 API to feed Kastr?
Query if you want it working this week; the v5 API if your team prefers to own a script. Both produce the same file and both POST to the same endpoint. Neither gives Kastr access to Aeries — the extract runs on your side either way, which is usually the deciding factor in a security review.
How do I exclude inactive and deleted Aeries students from the export?
Filter on the STU tag field for inactive students and exclude records marked deleted. Omitting either filter pulls years of former students, all of which arrive as new active records. You will see it immediately in the dry run as an implausible number of adds, which is the point of running the dry run first.
How does Kastr use the Aeries contact sequence number?
It becomes contact rank on the guardian edge. Rank drives the order shown to front-office staff and the order an escalating voice call walks down. Rank is stored per student rather than per person, so an adult can be first contact for one child and third for another without conflict.
Does Kastr touch CALPADS or any California state reporting?
No. Kastr submits nothing to CALPADS, reads nothing from it, and has no state-reporting function. That remains between your district and Aeries. Kastr is a communications platform and deliberately stays out of the compliance-reporting path.
Where do I store the Aeries API certificate key so it does not end up in a config file?
In your own secret store — a cloud secret manager, a vault, or an encrypted environment file on the job host. Kastr never needs the Aeries key. If someone tries to paste a credential-shaped string into a Kastr connector config, the save is rejected outright; you store a reference, not the secret.
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.