Developers
Help education software work together.
We are designing an open but reviewed developer ecosystem. CampusLayer may initiate integrations, and providers may approach us. School and district authorization will always remain a requirement for access to institutional data.
Canonical interoperability
Bring provider-specific data into an explainable, source-aware model. Proposed mappings are validated and versioned before production use.
Standards without lock-in
OneRoster 1.1 and 1.2 are planned versioned import/export interfaces, not a substitute for the underlying canonical model or each provider's rules.
Cross-system operations
Connect supplies reviewed capabilities. Sync is planned to expose reusable event-driven workflows through typed, governed actions.
Technical boundaries matter.
The current code includes an internal, read-only OneRoster 1.1 foundation and account-scoped Canvas connectivity. Public canonical APIs, OneRoster 1.2 endpoints, general write-back orchestration, and self-service provider registration are not available yet. API routes in the running application should not be interpreted as a stable public developer platform.