Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Taykl12/Classify/llms.txt

Use this file to discover all available pages before exploring further.

The admin role grants complete control over the Classify platform. Administrators manage the full user lifecycle, configure courses and subjects, assign professors, and monitor the ESP32 attendance hardware. The admin role is seeded directly in the database (id_rol = 1) and is the only role that can elevate other users to professor or admin status. All admin API routes are protected by the requireAdmin middleware, which validates both authentication and role before any operation is performed.

The Admin Panel

The admin panel is a dedicated section of the frontend accessible only to users with id_rol = 1. The <AdminRoute> wrapper redirects any non-admin user who attempts to navigate to these pages.
RouteDescription
/admin/dashboardOverview of platform activity and quick statistics
/admin/usuariosFull user list with role management
/admin/cursosCourse creation, editing, and deletion
/admin/materiasSubject management and professor assignment
/admin/proyectosPlatform-wide project overview
/admin/esp32ESP32 device status and controls

Platform Summary

The GET /api/admin/summary endpoint returns aggregate counts across the platform — total users, courses, and subjects — and powers the statistics displayed on the admin dashboard.
EndpointMethodDescription
/api/admin/summaryGETReturn total counts of users, courses, and subjects

User Management

Admins have full read and write access to all user records. This includes promoting students to professor, assigning the admin role, and updating user details.
EndpointMethodDescription
/api/admin/usersGETList all registered users
/api/admin/usersPOSTCreate a new user directly (bypasses registration flow)
/api/admin/users/:idPATCHUpdate a user’s details or role
/api/admin/users/:idDELETEDelete a user account
/api/admin/rolesGETList all available roles
An admin cannot delete or demote their own account through the UI. This safeguard prevents the platform from being left without an administrator.

Course Management

Courses are the primary academic unit in Classify. Admins create and maintain the course catalogue, and they control which students and professors belong to each course.
EndpointMethodDescription
/api/admin/cursosGETList all courses
/api/admin/cursosPOSTCreate a new course
/api/admin/cursos/:idPATCHUpdate an existing course
/api/admin/cursos/:idDELETEDelete a course
/api/admin/cursos/:id/usersPUTAssign or update users enrolled in a course

Subject Management

Subjects (materias) sit alongside courses and can be linked to professors. Admins manage the full subject catalogue and control which professors are responsible for each subject.
EndpointMethodDescription
/api/admin/materiasGETList all subjects
/api/admin/materiasPOSTCreate a new subject
/api/admin/materias/:idPATCHUpdate an existing subject
/api/admin/materias/:idDELETEDelete a subject
/api/admin/materias/:id/profesoresPUTAssign professors to a subject

ESP32 Device Monitoring

Classify integrates with ESP32 microcontrollers that handle physical attendance inputs (e.g., fingerprint readers). Admins can check the live status of connected devices and reset the press counter when needed.
EndpointMethodDescription
/api/admin/esp32/statusGETView current ESP32 device status and press counter
/api/admin/esp32/resetPOSTReset the ESP32 press counter to zero
The /admin/esp32 panel in the frontend displays the device status in real time and exposes the reset action with a confirmation prompt.

Service Role Key and Row-Level Security

The admin backend client is initialized with the SUPABASE_SERVICE_ROLE_KEY rather than the standard anon key. This allows admin operations to run with elevated privileges inside Supabase.
The SUPABASE_SERVICE_ROLE_KEY bypasses all Supabase Row-Level Security (RLS) policies. Any query made with this key can read and write any row in any table regardless of policy rules. Store it exclusively in your server-side environment variables and never expose it to the browser or include it in client-side bundles.
This design is intentional — admin operations such as listing all users or modifying any project need to cross RLS boundaries that would block the regular anon key. The tradeoff is that the service role key must be treated as a root credential for your database.

All Admin API Endpoints

All routes below require a valid JWT with id_rol = 1. Requests from users with any other role are rejected by the requireAdmin middleware.
GET    /api/admin/summary
GET    /api/admin/users
POST   /api/admin/users
PATCH  /api/admin/users/:id
DELETE /api/admin/users/:id
GET    /api/admin/roles

GET    /api/admin/cursos
POST   /api/admin/cursos
PATCH  /api/admin/cursos/:id
DELETE /api/admin/cursos/:id
PUT    /api/admin/cursos/:id/users

GET    /api/admin/materias
POST   /api/admin/materias
PATCH  /api/admin/materias/:id
DELETE /api/admin/materias/:id
PUT    /api/admin/materias/:id/profesores

GET    /api/admin/esp32/status
POST   /api/admin/esp32/reset

Build docs developers (and LLMs) love