Developer APIs
Build against clear contracts, not fragile provider assumptions.
CampusLayer is designing three governed API families so approved developers can use canonical education data, supported standards, or integration capabilities. These are architectural previews, not launched public endpoints.
Canonical API
One consistent, source-aware model for authorized organization, course, section, assignment, and operation requests.
Illustrative future routes: GET /v1/sections, GET /v1/assignments, POST /v1/operations.
Standards API
Version-scoped OneRoster 1.1 and 1.2 service and export adapters, with compatibility and conformance checked per binding.
1.1 and 1.2 are separate contracts. Current internal foundation only implements a subset of read-only 1.1.
Integration & Workflow API
Future provider event/capability registration, signed webhooks, authorized workflow definitions, and execution status.
Planned: provider submissions, sandbox validation, typed actions, and workflow runs.
Authorization comes before access.
Future APIs will use scoped authentication, tenant and provider authorization, rate limiting, idempotent write operations, auditable requests, and revocable access. A developer account will not grant access to real student records by itself.
Today, the existing application and internal routes should not be treated as a stable public API contract.