Who it’s for
- Platform administrators — Manage schools (clients), domains, and platform users via the system API.
- School staff — Teachers, principals, and office staff use the school API on their tenant domain for admissions, sessions, exams, marks, reports, and notices.
- Integrators — Use the REST API and optional WhatsApp chatbot for student/parent self-service (results, attendance, notices).
Key features
Multi-tenant architecture
django-tenants with schema-per-school. Public schema for clients, domains, and platform users; one schema per school for all academic and operational data.
WhatsApp chatbot
Webhooks, session-based flows, and optional LLM. Results, attendance, notices, and batch report PDFs. Celery/Redis for async processing.
Student and academic lifecycle
Admissions, session registration, forms, classes, exam sessions, exams, marks, report cards, teacher/head/class-teacher comments, promotions, and audit logs.
Dual authentication
System auth for platform admins (no tenant). School auth for tenant users (JWT with tenant context). Optional API keys for programmatic access.
Tech stack
- Backend: Django, Django REST Framework, django-tenants
- Database: PostgreSQL (one database; multiple schemas)
- Auth: JWT (access + refresh), API keys
- Cache & tasks: Redis, Celery
- API docs: drf-spectacular (OpenAPI 3), Swagger UI, ReDoc
Where to go from here
Quickstart
Clone, configure environment variables, run migrations, and start the server. Optional: PostgreSQL via Docker, Redis for production.
Architecture
Multi-tenancy, request flow (domain/JWT/X-Schema-Name), API layout (system vs school vs chatbot), and key subsystems.
Modules
Core (academic, students, assessment, settings, RBAC, audit), Clients, Authentication, and Chatbot — concepts and API overview.
API Reference
Full REST endpoint reference generated from the codebase. Use system vs school base URLs and JWT or API key as documented.