Skip to main content

Overview

Chat Sessions endpoints allow you to retrieve, list, and delete AI chatbot conversation history. Each session represents a conversation thread between a student and the SkillRise AI Assistant. All sessions are user-specific and secured by user authentication to ensure privacy.

GET /api/user/chat/:sessionId

Retrieve the complete message history for a specific chat session.

Authentication

Requires JWT authentication token in the Authorization header.

URL Parameters

string
required
The unique session identifier (UUID v4 format).

Response

string
MongoDB document ID for the chat session.
array
Array of all messages in the conversation.

Response Example

Error Responses

Implementation Notes

  • Uses MongoDB aggregation pipeline for efficient retrieval
  • Matches both sessionId and userId to ensure security
  • Returns only _id and messages fields (excludes metadata)
  • System messages (from context building) are included in the response

DELETE /api/user/chat/:sessionId

Delete a specific chat session and all its messages.

Authentication

Requires JWT authentication token in the Authorization header.

URL Parameters

string
required
The unique session identifier to delete.

Response

boolean
Indicates whether the deletion was successful.
string
Confirmation message.

Response Example

Error Responses

Implementation Notes

  • Uses findOneAndDelete with both sessionId and userId for security
  • Permanently removes the session and all associated messages
  • Returns 404 if the session doesn’t exist or doesn’t belong to the user
  • Cannot be undone - ensure user confirmation before deletion

POST /api/user/previous-chats

Retrieve a list of all chat sessions for the authenticated user.

Authentication

Requires JWT authentication token in the Authorization header.

Request Body

No request body required.

Response

array
Array of chat session summaries.

Response Example

Error Responses

Implementation Notes

  • Retrieves all sessions for the authenticated user
  • Selects only sessionId, messages, and updatedAt fields
  • Returns chats in reverse order (most recent first)
  • Uses the first message content as a preview/summary
  • Date is formatted using JavaScript’s toDateString() method
  • Empty array is returned if user has no chat sessions

Data Model

ChatSession Schema

Chat sessions are stored in MongoDB with the following structure:

Indexes

  • Composite index on (userId, sessionId) for efficient lookups
  • Sessions are user-scoped for security and privacy

Usage Patterns

Building a Chat History UI

  1. List View: Use POST /api/user/previous-chats to display all conversations
    • Show the first message as the conversation title
    • Display the updatedAt timestamp
    • Use sessionId as the navigation key
  2. Detail View: Use GET /api/user/chat/:sessionId to show full conversation
    • Render all messages in chronological order
    • Filter out system role messages if desired (they’re internal context)
  3. Deletion: Use DELETE /api/user/chat/:sessionId with user confirmation
    • Show a confirmation dialog before deletion
    • Redirect to chat list after successful deletion

Continuing a Conversation

To continue an existing conversation:
  1. Get the sessionId from the chat list or URL
  2. Make a new POST /api/user/ai-chat request with the sessionId in the body
  3. The AI will load the last 20 messages from the session for context
  4. The response includes the updated conversation history

Session Lifecycle

  1. Creation: Sessions are created automatically when a user sends their first message without a sessionId
  2. Updates: Sessions are updated each time a message is sent (user) or received (assistant)
  3. Persistence: Sessions persist indefinitely until explicitly deleted
  4. Security: Sessions are always filtered by userId to prevent cross-user access

Best Practices

  1. Pagination: For users with many chats, implement client-side pagination
  2. Caching: Cache the chat list and individual sessions to reduce API calls
  3. Optimistic UI: Update the UI immediately when sending messages, then sync with the server response
  4. Error Handling: Always handle 404 errors gracefully (session may have been deleted)
  5. Confirmation: Require explicit user confirmation before deleting sessions

Security

  • All endpoints require authentication via JWT token
  • Sessions are strictly user-scoped (userId is always matched)
  • Attempting to access another user’s session returns 404 (not 403) to avoid information leakage
  • Session IDs are UUIDs, making them difficult to guess

Performance Considerations

  • The chat list endpoint fetches all user sessions - consider pagination for power users
  • Individual session retrieval uses MongoDB aggregation for efficiency
  • Messages are not paginated within a session - very long sessions may cause performance issues
  • Consider implementing a message limit per session (e.g., 1000 messages)