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 | What your export should do | Why it matters |
|---|---|---|---|
CON.SQ | Contact sequence within the student | Use it to choose which contacts to send | A roster entry has no rank field, so Kastr never sees the order |
CON.CD | Relationship code (mother, father, guardian, other) | Use it with CON.ER to decide who goes in as a guardian | A roster entry has no relationship label |
CON.ER | Educational rights indicator | Send the adult as a guardian entry linked to the student | Gates whether the adult counts as a guardian at all |
CON.MC / mailing indicator | Receives district correspondence | Decide whether the adult belongs in the export; there is no consent field | SMS consent and opt-outs still apply to every text, urgent sends included |
CON.TP / phone fields | Home, work and mobile numbers | Put the mobile number in the entry's phone field | Only a mobile can take SMS, and there is no voice channel |
CON.EM | Email address | Put it in the entry's email field | Email is the other channel Kastr has |
CON.LG / STU.LF | Correspondence language | Send the adult's language as languagePref | Selects the DeepL target language for that family |
CON.RS / restriction flags | Restraining order or contact restriction | Leave the adult out entirely | Kastr cannot see the flag, so the export is the only place to act on it |
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 easiest shape for your job to turn into roster entries 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. Count the students in the batch before the first sync: thousands more than your active count 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 a cron job reshape it into JSON entries and POST them 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:
Generic roster-source 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. The dedicated OneRoster REST connection is separate: its client secret is accepted in the connection form and stored encrypted with AES-256-GCM.
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.
Text-message preferences. Kastr stores consent against the selected SMS contact point and checks opt-outs before sending. Importing a phone number does not grant text consent. ParentSquare opt-outs can be carried into Kastr through the reviewed contact import.
Reconciling the first sync
Before the nightly job goes automatic, reconcile four numbers between Aeries and the batch your job builds; there is no dry-run mode, so this check is the safety step. 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 should be one person. 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 the targeting to plan around: audiences resolve as the district, a school, a class, specific people or a saved group, so a school-level audience is something you choose at send time, while a grade-level one is a saved group you build once.
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 end up as the same JSON entries POSTed 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. Count the students in the batch before the first sync and you will see it immediately as an implausible number; there is no dry-run mode, so that count is the check.
What should our export do with the Aeries contact sequence number?
Use it in your export job to decide which contacts to send and which number to put in the phone field. A roster entry has no rank field, so Kastr does not receive the sequence itself.
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. The dedicated OneRoster REST connection is separate: its client secret is accepted in the connection form and stored encrypted with AES-256-GCM.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers or add-on modules. Normal messaging is included under a published fair-use allowance, with transparent cost recovery only above it.