Skip to main content
The Console API lives under /v1/console and provides admin-level management for the MIND platform. All console endpoints require specific permissions granted through the RBAC system.

​
Authorization

Console endpoints use permission-based authorization. Each endpoint requires a specific module permission:
ModuleControls
USER_MANAGEMENTUser CRUD, activate/deactivate
ROLE_MANAGEMENTRole CRUD, permission matrix
TENANT_MANAGEMENTTenant CRUD, branding, SSO, AI config
CASE_STUDIESCase study CRUD, avatars, voices, attaching documents
KNOWLEDGE_BASESVector collections + documents (cross-domain)
FEEDBACKStudent feedback dashboard
PROGRAMMESAcademic programmes that scope which case studies users can access
Each module supports four actions: can_view, can_create, can_edit, can_delete. Granting KNOWLEDGE_BASES.can_view to a faculty role, for example, lets that user browse documents in any collection without being able to upload or delete. If a user’s role lacks the required permission, the API returns: 
{
  "success": false,
  "error": "Permission denied: CASE_STUDIES.can_create required",
  "code": "AUTHORIZATION_ERROR",
  "details": {}
}

​
Base URL

All console endpoints use the prefix: 
https://staging-be.mind.miva.university/v1/console

​
How retrieval is organised

The knowledge base is a small set of building blocks shared across domains:
  • Collections are named vector groupings (case-studies, assessments, …). Each collection is one Qdrant collection on disk. Create as many as you need with POST /knowledge-base/collections.
  • Documents live in exactly one collection. Each document gets a stable id when it’s uploaded; that id is what other domains reference (and what’s stored on every vector as source_id).
  • Domains that need RAG hold a list of document ids. A case study’s document_ids, for example, is the set of documents the agent will retrieve from for that case study’s sessions. Empty list means no RAG.
The end-to-end flow for an admin attaching reference material to a case study:
  1. Browse the available collections — GET /knowledge-base/collections.
  2. Look at what’s in one — GET /knowledge-base/collections/{name}/documents — and pick existing documents to reuse, or skip ahead to upload.
  3. Either:
  4. Detach when no longer needed — DELETE /case-studies/{id}/documents/{doc_id}. Detach-only; the document survives for reuse.
Hard-delete (vectors gone, S3 file gone, references stripped from every case study) is a separate action via the knowledge base delete endpoint.

​
Programmes and access scoping

Students typically belong to a programme — MPH, MBA, MIT, MPA — and case studies declare which programmes may access them. The model is intentionally simple:
  • A programme is a tagged group identified by an uppercase code.
  • A user’s programme_codes is a list of those codes (a faculty member can span multiple, a student usually has one).
  • A case study’s programme_codes is the set of programmes allowed to see and start sessions for it.
  • Empty list on a case study = open to all programmes. Existing case studies keep working without any tagging.
At runtime, GET /v1/case-studies (the student-facing list) filters to case studies whose programme_codes intersect the requester’s, plus the open ones. POST /v1/sessions checks the same intersection, so a student can’t bypass the list filter by guessing an id. Console routes are unfiltered — admins and faculty see everything. The frontend can read a user’s programme_codes and resolved permissions in one call via GET /v1/users/me, then gate UI elements without per-action permission checks.