How to sync Tyler SIS with Kastr
Tyler districts are usually mid-size and usually under-served by SIS-specific documentation, which means the honest version of this page is short on partnership language and long on mechanics. There is no Tyler partnership and no certified connector. There is a scheduled extract, a POST, and a five-count reconciliation that tells you whether it worked.
| # | Count | Source of truth in Tyler | Expected relationship | If it does not match |
|---|---|---|---|---|
| 1 | Active students | Enrolment report, active status only | Exact match | Enrolment-status filter is wrong or includes transferred students |
| 2 | Student-guardian pairs | Contact/guardian extract row count | Exact match | Join is dropping rows — usually contacts with no phone |
| 3 | Distinct guardians | Distinct adults in the contact extract | Kastr lower than row count 2 | Equal means de-duplication failed; check identifiers |
| 4 | Students with an SMS-capable number | Contacts with a mobile phone type | Exact match | Phone type is not being exported; everything is voice-only |
| 5 | Students with zero contact points | Students absent from the contact extract | Exact match, and hand the list to the office | Silent unreachability — the most valuable finding of the whole exercise |
Count 5 is the one to run before you sign anything, with any vendor. In most districts it is between one and four per cent of students, and nobody knows the number until somebody counts it. It is not a Tyler problem — it is a rostering-hygiene problem that every SIS has, and the count is the only way to see it.
The extract
Tyler SIS can produce scheduled reports and extracts and deliver them to a district-controlled location. That is the whole mechanism. Build one extract joining student demographics, current enrolment and the contact or guardian entities, schedule it overnight, and have cron POST the file.
What to carry, and why:
- A stable student identifier. Local or state, but pick one and never change it. The diff engine matches on this; changing it converts your entire enrolment into a withdrawal followed by an addition.
- Enrolment status and school. Status decides roster state, school decides which organisation in the hierarchy the record belongs to.
- Contact name, relationship, and the lives-with, guardian and emergency indicators. These become the guardian edge and its rank. An emergency-only contact is not a guardian and should not receive routine sends.
- Phone number with its type, and email. Type is what separates an SMS-capable contact point from a voice-only one.
- Preferred language, per adult where Tyler holds it per adult, not inherited from the student.
Alternatively, if your district publishes to Clever or ClassLink already, take students, staff and sections from that broker feed and only build a small Tyler extract for guardian contacts. For districts under about 5,000 students the direct extract is usually less total work; above that, if a broker is already running, reuse it.
Enrolment status, and the end-of-year pattern
Tyler's status codes vary by district configuration, but the translation follows the same shape everywhere: active means active, inactive and transferred mean withdrawn, and historical records should not be in the file at all.
The pattern to plan for is the last week of the year. When a district closes out enrolments in bulk — graduating seniors, transfers processed in a batch, the year-end status sweep — a nightly export can legitimately contain a fraction of the previous night's roster.
What happens: if accepting the file would withdraw more than half of active records, the run aborts, records aborted_guardrail, and writes nothing. The previous roster stands. This is the correct behaviour and it is why the guardrail was built — the alternative is a silent overnight mass withdrawal that nobody notices until September.
What to do: pause the nightly POST for the close-out window and run it manually with --dry-run. Read the ledger. Resume when the numbers look like a school district again.
A 30% withdrawal night passes the guardrail and is still probably wrong. The guardrail is a floor, not a substitute for reading the ledger during the two weeks a year when your SIS is being reorganised.
What Kastr will not do with your Tyler stack
Tyler Technologies sells a lot of things to school districts, and it is worth being explicit about where the line sits.
No transportation integration. Kastr does not read Tyler's transportation products, does not know your bus routes, and has no geofencing of any kind. Bus-delay messaging is possible only in the sense that a human can compose and send a message about a bus. If a vendor tells you they geofence bus alerts, ask to see it running.
No ERP or finance integration. Kastr does not read Tyler's ERP, municipal or finance products. Lunch-balance notices are not automated; the rules configure and no engine fires them.
No write-back. Nothing Kastr knows flows back into Tyler SIS. Message history lives in Kastr and is available through the REST API if you want it in a warehouse.
No partnership. We are not a Tyler partner and there is no certified connector to point at in a procurement document. What there is instead: a documented endpoint, an MIT-licensed CLI you can read, and a contract clause — §7.1 — giving you the right to export everything at any time, machine-readable, without fee. That right is a contract term rather than a self-serve button today, and we would rather say so than let you find out at renewal.
Cadence, and what happens between syncs
Nightly is right for almost everyone. Rostering data changes on a school-day rhythm, and a nightly diff at 02:00 gives the SIS time to finish its own overnight work before anything is read.
Two adjustments worth making. In the first three weeks of the school year, run twice daily — enrolment churn is at its annual peak and a family that enrols on Tuesday morning should not wait until Wednesday to be reachable. During the rollover and close-out windows, run manually.
Between syncs, corrections still happen. A front-office administrator can edit a contact point directly in Kastr, and that edit is recorded with its source. On the next sync the SIS value is compared against the stored hash, so a hand correction that the SIS then overwrites is visible in the ledger as a change rather than vanishing silently — which tells you the real fix belongs in Tyler.
Every run writes to a per-organisation append-only audit log, hash-chained with SHA-256 and protected at two independent layers: the database role has no UPDATE or DELETE permission on the table, and the row-level security policies define no UPDATE or DELETE path. Rewriting history is not a permissions question, it is not possible through the application at all.
Questions people actually ask
Does Kastr have a Tyler Technologies partnership or native connector?
No to both. There is no partnership, no certified connector and no Kastr code that authenticates to Tyler SIS. The integration is a scheduled Tyler extract, delivered to storage your district controls, POSTed to a documented endpoint by a job you own. That is less impressive on a slide and considerably easier to audit.
Is it easier to roster Tyler SIS through Clever or with a direct extract?
Below roughly 5,000 students, the direct extract is usually less total work because there is one system to configure rather than two. Above that, or if a broker is already running for other applications, reuse the broker for students and sections and build a small Tyler extract for guardian contacts — which is the part brokers cover least well.
How do I reconcile Tyler's student count against the Kastr dry run?
Check five numbers: active students, student-guardian pairs, distinct guardians, students with an SMS-capable number, and students with zero contact points. The first, second, fourth and fifth should match Tyler exactly. Distinct guardians should be lower than the pair count, because one adult across three children is one person here.
What happens to a Tyler student marked transferred mid-year?
They classify as a withdrawal in the next diff and the enrolment is marked withdrawn in the audit log. Be aware of the current gap: the send path does not yet filter on enrolment state, so removing that family from an existing saved audience is a manual step today. We would rather write that down than let you assume otherwise.
Does Kastr integrate with Tyler's transportation or ERP products?
No. Kastr reads no Tyler product other than the roster extract your district produces, knows nothing about bus routes, and has no geofencing. Lunch-balance and attendance notices are not automated either — rules can be configured but no engine runs them yet.
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.