Skip to main content
Meridian Academic OS logo
Meridian Academic OS

API

Canonical integrations, shaped for developers.

Meridian APIs follow the same entities and workflow ideas used inside the product, so integrations stay aligned with the canon instead of drifting into a separate model.

Request sandbox access
Identity and access Academic structure Workflow events

Authentication and sandbox access

Request sandbox credentials before you start coding. Integration keys should be kept private and scoped to the minimum access required for the workflow you are building.

  • Use test credentials while mapping the data shape.
  • Promote a key only after the workflow is validated.
  • Keep authorization aligned to roles and functions, not just a broad admin token.

Resource families

The examples below describe the kinds of resources Meridian APIs are expected to expose. Final route names can be adapted to your implementation, but the structure should stay close to the canon.

identity / access

Users, roles, and memberships

Look up the people, roles, and group memberships that control access and ownership in the system.

Scoped accessAudit-friendly
academics / structure

Programs, cohorts, sections

Expose the academic model so external tools can stay aligned with the same organizational structure.

Canon mappedStable shape
workflows / events

Approvals and follow-ups

Send and receive events that describe approvals, interventions, follow-up actions, and closure states.

Event-drivenTraceable
audit / exports

Logs and governance views

Export the evidence needed for reviews, reporting, and support without exposing more data than necessary.

Evidence built inLimited scope

Example request shape

This sample is intentionally simple. It shows how a workflow request might look when it is read by another system or integration partner.

HTTP example 
GET /v1/workflows/attendance-follow-up
Authorization: Bearer your_sandbox_key

{
  "id": "wf_1024",
  "owner": "class_teacher",
  "status": "open",
  "evidence": ["note", "approval", "closure_status"]
}

Rate limits and versioning

Keep integrations polite, keep payloads small, and keep version changes explicit. If a workflow depends on a particular response shape, pin it to a known version before wider rollout.

  • Prefer small, focused calls over broad payloads.
  • Minimize the data you request and store.
  • Review any version bump in a test environment before release.

API

Canon-consistent integrations

APIs follow the canonical entities and events in meridian-canon, so your integrations stay aligned with in-app data.

Core domains

  • Identity & access: users, memberships, person-role assignments, scoped RBAC.
  • Academics: programmes, cohorts, sections, progression levels.
  • Workflows: attendance, assessments, interventions, approvals, evidence.
  • Exports: closure status, risk flags, audit logs for governance reviews.

Getting started

  • Request sandbox credentials at hello@nagu.co.
  • Use the school-pack endpoints for active delivery; other packs are in planned status.
  • Follow rate limits and data minimization guidance in the docs.

Return to home