Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Daniel-Stojanovski/finkiopendesk/llms.txt

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

FinkiOpenDesk notifies you when someone posts a new comment in a discussion thread you have participated in. Notifications are grouped by discussion context — one group per subject, profession, or channel discussion — so related activity is consolidated rather than scattered as individual alerts.

How notifications are triggered

Every time a comment is created successfully, the backend’s NotificationService checks which users have previously commented in the same discussion and sends a notification event to each of them.
Notifications are tied exclusively to comment activity. Other actions — such as voting, favoriting, or viewing a roadmap — do not generate notifications. You will only receive a notification if you have already posted at least one comment in the relevant discussion.

Notification structure

Notifications arrive in two levels: Group — one per discussion context (e.g., one group for “Algorithms” subject discussion)
interface NotificationGroupDto {
  notificationGroupId: string;
  userId: string;
  type: string;          // "subject", "profession", or "channel"
  contextId: string;     // the subject/profession/channel ID
  title: string;         // human-readable name of the discussion
  unreadCount: number;   // count of unread events in this group
  events: NotificationEventDto[];
}
Event — one per individual comment that triggered a notification
interface NotificationEventDto {
  notificationEventId: string;
  initiatorId: string;   // user who posted the comment
  type: string;
  message: string;
  targetObjectId: string;
  statusRead: boolean;
  contextId: string;
  groupType: string;
}
The unreadCount on a group gives you a quick total of unseen events without expanding the group.

Notification flow

1

You post a comment

You post a comment in any subject, profession, or channel discussion. The system records your participation in that discussion context.
2

Another user posts in the same discussion

When a different user submits a comment to the same discussion, the backend creates a notification event for every prior participant — including you.
3

The notification is grouped

The new event is attached to the notification group for that discussion context. If no group exists yet for you and that discussion, one is created. The group’s unreadCount increments.
4

You open notifications

Your notification list is fetched by user ID. Groups with unread events are highlighted. Expand a group to see individual events — who posted, what they said, and when.
5

Mark as read

Mark a single event as read, or mark the entire group as read at once. The unreadCount on the group drops to zero when the group is fully read.

API endpoints

Fetch your notifications:
GET /api/notifications/{userId}
Returns a list of NotificationGroupDto objects for the given user, each containing its nested events. Mark a single event as read:
POST /api/notifications/event/{eventId}/read
Mark an entire group as read:
POST /api/notifications/group/{groupId}/read
Marking a group as read sets all of its events’ statusRead flag to true in a single operation, which is more efficient than marking each event individually when a group has many unread items.

Build docs developers (and LLMs) love