Standards
A OneRoster API layer schools can own
Publish OneRoster v1.1 and v1.2 endpoints through Cloudflare Workers while keeping each tenant on district-controlled D1 or Postgres storage.
Open-source roster data gateway Roster data gateway
OpenRoster
OpenRoster is an open, multi-tenant OneRoster gateway for districts that need to share roster data without giving up control of it. Approve each vendor by field, context, and time window; mask sensitive identifiers; and serve standards-based APIs from infrastructure your team can inspect.
01
Approve exact fields
02
Filter roster context
03
Mask sensitive IDs
What changes
Move from roster exports to enforceable data grants.
OpenRoster is not trying to be another classroom portal. It is the data boundary between school-owned roster systems and the vendors asking for access: standards-based APIs, precise grants, masked identifiers, and inspectable infrastructure.
Grants
App grants before API tokens
Vendors request the data they need, and districts approve the API, entities, fields, context filters, and grant dates before credentials can return data.
Policy
Least-privilege responses by default
The API validates requested fields, rejects unauthorized filters, applies record context, and omits anything outside the approved grant.
Privacy
Masked identifiers without broken integrations
Sensitive attributes can be returned as protected values, letting an app match records without receiving plain-text identifiers it does not need.
Open
Open infrastructure your team can inspect
The grant model, API handlers, metadata, and worker configuration live in an open codebase so districts are not forced to trust a black box.
Review
Evidence for every integration review
Application profiles capture requested permissions, audiences, integration types, screenshots, and granted access so reviews stay concrete.
Deployment model
Run the roster gateway where your data policy requires it.
Each tenant can map to its own Cloudflare D1 database or a Postgres database reached through Hyperdrive. The Worker enforces app grants on every request, so district policy sits in the response path instead of in a spreadsheet, file export, or vendor ticket queue.
View deployment notes grant-enforced data path
privateSchool district
data steward
Worker binding
OpenRoster
OneRoster API, app grants, field rules, context filters, token issuance, and masked attributes.
Database tenant-owned
Runtime Workers
Access grant-gated
Security model
Turn every vendor request into an API-enforced contract.
For district admins, every app request becomes a visible route through three controls: field permissions, record context, and masked PII handling before roster data reaches a third party.
OpenRoster sharing route
admin grant preview
District SIS
students, classes, guardiansOpenRoster
policy engineMath app Security configuration
Attributes
Users
givenNamefamilyNamegrades identifier emailphone
Classes
titleclassCodeschoolterms location
Enrollments
roleuserclassschool beginDateendDate
Records
Classes.school = Lincoln MiddleClasses.grades includes 07Classes.subjects includes MathematicsEnrollments.role = student
Masked PII
Users.identifier maskedUsers.email blocked
Math app
Library Security configuration
Attributes
Users
sourcedIdgivenNamefamilyNamegrades userIds emailphone
Orgs
sourcedIdnametype identifier
Enrollments
userschoolrole class
Records
Users.status = activeOrgs.type = schoolEnrollments.school in approved schools
Masked PII
Users.userIds maskedUsers.email blocked
Library
Analytics Security configuration
Attributes
Users
sourcedIdgradesprimaryOrg userMasterIdentifier givenNamefamilyNameemail
Classes
gradessubjectssubjectCodesterms location
Enrollments
roleclassbeginDateendDate user
Records
Classes.terms = current school yearEnrollments.status = activeUsers.primaryOrg in district
Masked PII
Users.userMasterIdentifier maskedUsers.email blocked
Analytics
Audit every outbound share
Which app received which data, from which source, under which policy.App Data From Policy
Math app Users.givenName, Classes.title, Enrollments.role Users + Classes + Enrollments Lincoln MS · Grade 7 math
Library Users.sourcedId, Users.familyName, Orgs.name Users + Orgs + Enrollments Active students · All schools
Analytics Classes.subjectCodes, Enrollments.beginDate Users + Classes + Enrollments District view · masked IDs
governed release
Every app gets its own access recipe and audit trail.
scoped records approved attributes masked PII
The contrast
OpenRoster is built for districts that want the roster boundary in their hands.
Data brokers & existing middlemen all speak to automation, privacy, and data exchange. OpenRoster narrows the promise: an open gateway that enforces exactly what each application can receive.
Decision point
OpenRoster
Proprietary platforms
Primary job
Protect roster data while publishing standards-based APIs
Bundle rostering into an identity portal, marketplace, or data exchange
Data ownership
Self-hostable with tenant storage in D1 or Postgres
Vendor-hosted workflows that are harder to inspect or change
Grant shape
Fields, masked fields, record context, API version, and grant window
App-level rules, sync settings, or custom files with less visible policy
PII posture
Mask or omit before the API response leaves the gateway
PII protection often depends on add-ons, policy review, or vendor-side handling
Implementation surface
Open-source Worker services and public OneRoster-compatible routes
Closed product roadmap, bundled services, and contract-defined limits
Start with ownership
Publish roster APIs with the district still in control.
Use OpenRoster when the requirement is specific: standards-based roster access, field-level grants, context filters, masked identifiers, and infrastructure your team can inspect.