How to sync Blackbaud Education Management with Kastr
Kastr has no Blackbaud connector and is not a Blackbaud partner. What works is an OAuth2 client against the SKY API, a nightly job that reshapes users, roles and relationships into Kastr's roster form, and a POST. This page is that map, plus two things an independent school's business office will want stated before a board meeting: where our pricing actually starts, and what we will never do with your families.
| SKY resource | Becomes in Kastr | Carry across | Watch for |
|---|---|---|---|
| Users (student role) | A student entry | Stable user ID, legal and preferred name, school | Preferred name is the one families expect to see in a message |
| Users (parent role) | A guardian entry | Stable user ID, email, phone with type | One adult is frequently a parent at two divisions, one identity, two roles |
| Users (faculty/staff role) | A teacher entry, for teaching staff | Stable user ID, work email, mobile | Staff who are also parents must not become two people |
| Roles | Which role each entry carries | Role type, start and end dates | Alumni and past-parent roles should not be carried into a comms roster |
| Relationships | guardianOfSourceId on the guardian entry | Relationship type, both user IDs, direction | Who is included is your decision, so make it deliberately |
| Enrolment / grade level | Who is in the batch | Division, grade, academic year | Lower, middle and upper school are usually separate schools, so check counts per division |
| OAuth2 client secret | Nowhere in Kastr | A reference only | Connector configs hard-reject a pasted literal credential |
For a custom Blackbaud integration, map to the JSON roster API contract at /integrations/roster-sync-api. The native OneRoster connector uses a different input format and preview/apply engine.
Relationship types, and who actually gets the message
Independent schools handle household complexity constantly, divorced parents in separate households, a grandparent who does the school run, a guardian who is not a parent, an emergency contact who must never receive routine mail. Blackbaud carries that structure. The job is to translate it into guardian entries that produce the right recipient list at 5:40am on a snow day. A roster entry has no rank, so every decision below is about who goes in.
- Parent, lives with student → guardian entry. Receives everything.
- Parent, separate household → guardian entry as well, unless a court order says otherwise. Both parents generally retain access to records and to communication; the default should be inclusion, and exclusion should require a documented reason.
- Step-parent or partner → guardian entry, if the family has asked for it. Confirm rather than assume.
- Grandparent or other caregiver acting as guardian → guardian entry where the arrangement makes them a guardian. Where they do pickup but not decisions, decide deliberately whether they belong in the export.
- Emergency contact only → not in the export. A roster entry has no emergency-only setting, and an emergency contact should not receive newsletters; a system that cannot tell the difference will annoy them into unsubscribing before the day you need them.
- Alumni parent, past parent, trustee, donor → not in the comms roster at all. Filter these out at the extract, not afterwards.
One structural advantage worth knowing about: Kastr models one person with many effective-dated roles rather than one account per hat. A teacher whose two children attend the school is a single identity with three roles, so she is not messaged three times, and when her staff role ends in June the guardian roles are unaffected. Split households and staff-who-are-also-parents collapse correctly rather than needing manual de-duplication every August.
Fit, stated plainly, for a school under 1,000 students
An honest answer rather than a sales one. Kastr's published pricing starts at $3.50 per student per year for districts under 5,000 students, and the price list is built for public districts. A school of 400 students is below the band the pricing was designed around. That does not make it impossible, it means the annual number is small enough that we would rather you understood the whole commercial picture before deciding, and it means you should ask us directly rather than reading a tier off a page.
What an independent school board tends to care about, and where each sits:
- Price certainty. One tier, everything included. No marked-up message fees, no per-module charges, no integration fee. Fixed for 36 months, and from year four capped at the lesser of CPI-U or 5% under clause 3.2 of the agreement. A board that has been through a mid-term price increase with another vendor will recognise why that clause exists.
- Data portability. Clause 7.1 gives you the right to export everything, machine-readable, at any time and without fee. Be clear about what that is and is not: it is a contract right, and the self-serve tooling to exercise it in one click has not been built. Today it is a request we fulfil, not a button you press.
- Change of control. Clause 11.2 gives you an exit if Kastr is acquired. Independent schools ask this question more often than districts do, and it is a reasonable question given what has happened to this category.
- What we are not. Kastr is independently operated, is not SOC 2 audited, has limited reference history and no case studies to offer you, and has no SSO of any kind, magic link is the only authentication, for staff and families alike. If your board requires SAML or MFA, we are not a fit today and we would rather say so in writing.
The advancement boundary, and what the sync does not touch
In an independent school the fundraising database frequently sits next to the academic one, sometimes in the same product family, and the reasonable worry is whether a communications vendor becomes another party with an interest in your families' wallets.
The position is contractual rather than aspirational. Clause 9.4 of our agreement prohibits monetising family data, ever, no advertising, no data sales, no marketing to families, no premium family tier, no upsell inside a school message. Kastr generates no family-facing revenue by design; the district or school is the only customer. That clause exists because the incentive it removes is the one that has damaged this category most.
Operationally the boundary is just as blunt. Only pull what a comms roster needs: users, roles, relationships, contact points, enrolment. Do not pull giving history, do not pull constituent records, do not pull anything from an advancement module. There is nothing in Kastr that would use it, and a field you did not export is a field nobody has to reason about later. The connector is one-directional in any case, Kastr never writes back to Blackbaud, not contact corrections, not message logs, not anything.
The mechanism from there is the same as everywhere else on this site: a scheduled job on your infrastructure POSTs JSON entries to POST /api/v1/roster/sync; the diff engine hashes each record with SHA-256 and classifies add, change, unchanged or withdraw; a run that would withdraw more than half of active records aborts with an HTTP 409, records aborted_guardrail and writes nothing. The custom JSON roster API has no dry-run mode, so reconcile the counts in the first batches against Blackbaud before each POST. For a school of 600, expect a day of one person's time, most of it spent deciding who belongs in the export rather than writing code.
Questions people actually ask
Does Kastr connect to Blackbaud's SKY API directly?
No. There is no Blackbaud connector and no partnership. Your school writes an OAuth2 client that pulls users, roles and relationships, reshapes them into Kastr's roster form, and POSTs the result to a documented endpoint. The job runs on your infrastructure with credentials you hold; Kastr never authenticates to Blackbaud and the client secret never enters a Kastr connector config, which rejects pasted literal credentials outright. The dedicated OneRoster REST connection is separate: its client secret is accepted in the connection form and stored encrypted with AES-256-GCM.
Is Kastr appropriate for an independent school under 1,000 students?
Possibly, but our published pricing starts at the under-5,000 band at $3.50 per student per year and was designed around public districts, so a school of 400 sits below the shape the price list assumes. Ask us directly rather than inferring a number. Also weigh the gaps honestly: no SSO or MFA of any kind, no SOC 2 audit, independently operated, and limited reference history to give you.
Will Kastr touch our advancement or donor data?
No, and you should not export it. Pull only users, roles, relationships, contact points and enrolment. Beyond that, clause 9.4 of our agreement prohibits monetising family data in any form, no advertising, no data sales, no marketing to families, no premium family tier. Kastr generates no family-facing revenue by design, and the sync is one-directional so nothing flows back into Blackbaud either.
How are Blackbaud relationship types turned into who receives an urgent message?
In your export job. Each relationship you include becomes a guardian entry linked to the student; a roster entry has no rank, so the decision is who goes in. Parents in both households normally go in unless an order says otherwise; step-parents and caregivers go in where the family has asked; emergency-only contacts stay out, because a roster entry has no emergency-only setting. One person holds many effective-dated roles, so a teacher with two children enrolled is one identity rather than three records.
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.