Nineteen systems, and what each one can do.
Nineteen systems. Fifteen take the finished schedule back over their own API; Canvas through its own import file; PowerSchool as a reviewed handoff file your administrator imports. Clever is read-only, and SchoolRunner does not get the schedule back yet. Anything not on this list comes in as a spreadsheet.
The full list.
What comes in is the same for every system: students, teachers, courses, sections, rooms and current enrollments. Course requests come from the system where it has a feed, and as a spreadsheet where it does not (OneRoster has no request feed).
| System | How it connects | Administrator setup | Finished schedule returns | How delivery is confirmed |
|---|---|---|---|---|
| PowerSchool | OAuth 2.0 client credentials | A server or district administrator installs and enables a PowerSchool plugin that grants the read permissions, then copies that plugin’s own OAuth Client ID and Client Secret. | As a reviewed handoff file | Your administrator confirms the import; the download alone is not proof |
| Blackbaud | Sign in with the vendor, or API credentials | Register a confidential SKY application, add a School API subscription, and have a user with Marketplace permission connect the application to the school and approve its scopes. | Yes, over the API | The system’s own response, on the verify page |
| Veracross | OAuth 2.0 client credentials | A Veracross system administrator creates a client-credentials OAuth application in Data API v3 with the listed scopes and copies its Client ID and Client Secret. | Yes, over the API | The system’s own response, on the verify page |
| Aeries | REST with an API certificate | A district administrator creates a dedicated API certificate under Security → API Security with Read on each listed security area. | Yes, over the API | The system’s own response, on the verify page |
| Infinite Campus | OneRoster 1.1 (base URL, client ID and secret) | Infinite Campus must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| FACTS | OneRoster 1.1 (base URL, client ID and secret) | FACTS SIS must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Skyward | OneRoster 1.1 (base URL, client ID and secret) | Skyward must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Synergy | OneRoster 1.1 (base URL, client ID and secret) | Synergy SIS must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Focus | OneRoster 1.1 (base URL, client ID and secret) | Focus must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Rediker | OneRoster 1.1 (base URL, client ID and secret) | Rediker (Administrator's Plus) must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| ClassLink | OneRoster 1.1 (base URL, client ID and secret) | ClassLink must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Frontline | OneRoster 1.1 (base URL, client ID and secret) | Frontline must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Genesis | OneRoster 1.1 (base URL, client ID and secret) | Genesis must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Illuminate | OneRoster 1.1 (base URL, client ID and secret) | Illuminate must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Sycamore | OneRoster 1.1 (base URL, client ID and secret) | Sycamore must turn on its OneRoster 1.1 REST provider for the district and issue a Base URL, an OAuth Client ID and a Client Secret with the read permissions enabled. | Yes, over the API | The system’s own response, on the verify page |
| Canvas | Access token; the schedule goes back as an SIS Import CSV | An account that can read the whole roster creates a personal access token under Profile → Settings → Approved Integrations. | Yes, as its own import file | The system’s own response, on the verify page |
| QuickSchools | REST with an API key | An administrator turns on the App Developer Console and creates a dedicated API key. | Yes, over the API | The system’s own response, on the verify page |
| Clever | REST with a district token | The district authorizes the nOS Secure Sync application in Clever and copies its district token from the Clever developer dashboard. | No — read-only | Nothing goes back |
| SchoolRunner | REST with a username and password | SchoolRunner support confirms the tenant has the REST API and issues a read-only API username and password. | Not yet | Nothing goes back |
Administrator setup, every time
No connection is a single click. Your SIS administrator issues the credentials (a base URL and client keys, an API key, or a sign-in with the vendor), pastes them into Settings, and tests the connection before anything is imported. We will do it with you on a call.
What a send does
Additive only. Sections created and updated, enrollments added, rooms set. Nothing in your system is deleted, and you approve the whole list first. For PowerSchool the same list becomes a reviewed handoff file your administrator imports; the table above says which systems that applies to, and which get nothing back yet.
How you know it landed
An API write or a submitted import file is confirmed by the vendor's own response, on the verify page. A handoff file is confirmed when your administrator says they imported it; the download by itself is never treated as delivery.
Your student information system stays the system of record for enrollment, grades, attendance and reporting. nOS replaces the scheduling step, not the system.
We will connect yours on the call.
Bring credentials and an administrator and we can be reading real course requests inside the demo — or connect it yourself inside the thirty-day trial.