Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Pragyat-Nikunj/Learning-Management-System-backend/llms.txt

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

The LMS Backend exposes a versioned REST API over HTTP. Every endpoint lives under the /api/v1 prefix, accepts JSON request bodies, and returns JSON responses with a consistent structure. Before you call any protected endpoint, you need a valid session cookie obtained by signing in — the API does not use bearer tokens in headers.

Base URL

All requests must be sent to the following base URL. The port is controlled by the PORT environment variable on the server; the default used in development is 4000.
http://localhost:4000/api/v1
In production, replace http://localhost:4000 with your deployed server’s origin. The /api/v1 prefix is always required.

Authentication

The API uses JWT-based authentication. The token is issued as an HTTP-only cookie named token when you sign in. You do not need to read or manage the token manually — your HTTP client must simply send cookies with every request.
# The token cookie is set automatically on sign-in.
# On subsequent requests, pass credentials: true (fetch) or --cookie-jar (curl).
curl http://localhost:4000/api/v1/user/profile \
  --cookie "token=<your_jwt_token>"
The cookie is HTTP-only, so it cannot be read by JavaScript running in the browser. This protects the token from XSS attacks.
Protected routes use the isAuthenticated middleware, which reads req.cookies.token and rejects the request with 401 if the cookie is absent or the token is invalid. See Authentication concepts for a full explanation of the sign-in flow.

CORS

The server only accepts cross-origin requests from the origin configured in the CLIENT_URL environment variable (defaults to http://localhost:5173). Requests from any other origin will be blocked by the browser before they reach the API. The following HTTP methods are permitted: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS.
If you are calling the API from a browser-based app hosted at a different origin, you must set CLIENT_URL on the server to match your frontend’s origin exactly — including scheme, host, and port.

Rate limiting

All /api/* routes are protected by a global rate limiter.
WindowLimit per IP
15 minutes100 requests
Exceeding the limit returns an HTTP 429 response with the message:
Too many request from this IP, please try later

Request format

Send all request bodies as JSON with the Content-Type: application/json header. The server enforces a 10 KB maximum body size.
curl -X POST http://localhost:4000/api/v1/user/signup \
  -H "Content-Type: application/json" \
  -d '{"name": "Ada Lovelace", "email": "ada@example.com", "password": "hunter2"}'
The POST /api/v1/payments/webhook endpoint is the sole exception — it requires a raw binary body (application/json without JSON parsing) because Stripe signs the raw bytes for webhook verification.

Response format

Every response — success or error — is a JSON object. Successful responses follow this shape:
{
  "status": "success",
  "message": "...",
  "data": { ... }
}
Error responses use "status": "error" for 5xx codes and "status": "fail" for 4xx codes. See Error responses for the full error schema and a list of all status codes.

Available endpoints

Health

GET /api/v1/healthcheck — Verify the server and database are reachable.

Users

/api/v1/user/* — Sign up, sign in, profile management, password reset, and account deletion.

Courses

/api/v1/courses/* — Create, search, publish, and manage courses with thumbnail uploads.

Progress

/api/v1/progress/* — Track per-lecture completion and mark courses as fully completed.

Payments

/api/v1/payments/* — Stripe Checkout sessions, webhooks, and purchase status queries.

Example: authenticated request

The following curl command logs in and captures the session cookie to disk, then uses that cookie to fetch the authenticated user’s profile. This pattern works for any protected endpoint.
curl -X POST http://localhost:4000/api/v1/user/signin \
  -H "Content-Type: application/json" \
  -c cookies.txt \
  -d '{"email": "ada@example.com", "password": "hunter2"}'
When using a browser-based client such as fetch, pass credentials: "include" so the browser automatically attaches the token cookie on every request.

Build docs developers (and LLMs) love