[ EXTENSIONS WITH SCHOOL BOUNDARIES ]
Developer platform
Build school tools with explicit roles, tenant scope, and minimal data.
Authorize every request
Identify the school, user role, and class scope at the server. Do not rely on a client-provided school or class identifier.
Keep telemetry small
Exclude student prompts, answers, credentials, and personal identifiers from logs and error reports. Retain only fields needed to operate the extension.
Design for retries and revocation
Make repeated requests safe. Test timeouts, denied access, revoked roles, and attempts to cross a class or school boundary.
Keep school authorization in the server path
An integration must use the authenticated user and the correct school context. Do not trust a class ID or role supplied by the client as authorization. Check membership and resource access before returning documents, conversations, or tool results.
Design for cancellation and partial failure
A model stream can end early, a file can still be processing, and one response in a multi-model request can fail. Show each result accurately and allow a useful retry. Record usage and release reservations even when the client disconnects.
Use synthetic records while building
Exercise student, teacher, administrator, and unrelated accounts with synthetic records. Verify that changing account or school clears prior results. Never test access boundaries by browsing real student records from another class.
Discuss a supported integration
Contact Nexus with the intended workflow, the systems involved, and the data each system needs. API availability and deployment details should be confirmed for the school's setup; this marketing page is not an unrestricted public API credential.