Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/tech-dipesh/yeti-Jobs/llms.txt

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

Yeti Jobs includes a notification system that records user-scoped events across the platform’s major workflows. When something worth knowing happens — a company posts a new job, your application status changes, or your resume analysis completes — a notification row is written to the notifications table and becomes retrievable through the notifications API. Notifications are linked to the user who should receive them via the users_id foreign key, ensuring each user sees only their own alerts.
Notifications are stored in the PostgreSQL database and delivered via API polling. There is no WebSocket or server-sent event connection — the frontend must call GET /api/v1/notifications/all to refresh the notification list. Real-time push delivery via Socket.io is listed as a future improvement in the project roadmap.

Notification Types

The type field is enforced against a fixed set of values in the controller. Every notification must be one of the following ten types:
TypeDescription
new_jobsA company your account is associated with has posted a new job listing.
application_statusThe status of one of your applications has been updated by a recruiter.
job_alertA job matching your saved criteria has become available.
bookmark_reminderA reminder related to a job you have bookmarked.
company_followA user has followed a company you manage (recruiter-facing).
application_recievedA recruiter’s company has received a new application (note: intentional spelling in schema).
profile_viewAnother user has viewed your profile.
message_recievedA message has been received (note: intentional spelling in schema).
resume_analysedYour resume upload and ATS analysis has completed successfully.
announcementA platform-wide announcement from an admin.

API Endpoints

Fetch All Notifications

Retrieve all notifications for the authenticated user, ordered by created_at DESC (newest first). The query joins the jobs and companies tables so each notification also carries the job title and company name for display.
GET /api/v1/notifications/all
curl https://yeti-jobs.onrender.com/api/v1/notifications/all \
  -H 'Cookie: token=<your_jwt_token>'

Mark All as Read

Set read_at to the current timestamp for every unread notification belonging to the authenticated user. Useful for a “mark all read” button in the UI.
PATCH /api/v1/notifications/read-all
curl -X PATCH https://yeti-jobs.onrender.com/api/v1/notifications/read-all \
  -H 'Cookie: token=<your_jwt_token>'

Send a Notification

Manually create a notification record for the authenticated user. The type field must be one of the ten values listed above. Both job_id and company_id must be valid UUIDs — the middleware validates UUID format before the controller runs.
POST /api/v1/notifications/:id
job_id
string (UUID)
required
The UUID of the job this notification relates to.
company_id
string (UUID)
required
The UUID of the company this notification relates to.
type
string
required
The notification type. Must be one of the ten values listed in the table above.
curl -X POST https://yeti-jobs.onrender.com/api/v1/notifications/{notification_id} \
  -H 'Content-Type: application/json' \
  -H 'Cookie: token=<your_jwt_token>' \
  -d '{
    "job_id": "a3f2c1d4-89ab-4e56-b123-000000000001",
    "company_id": "b7e1a2f3-0000-4cde-9876-000000000099",
    "type": "application_status"
  }'

Mark a Single Notification as Read or Unread

Toggle the read state of one notification. Use the isRead query parameter to control the direction: true sets read_at to the current timestamp, false clears read_at back to null.
PATCH /api/v1/notifications/:id/read
# Mark as read
curl -X PATCH "https://yeti-jobs.onrender.com/api/v1/notifications/{notification_uid}/read?isRead=true" \
  -H 'Cookie: token=<your_jwt_token>'

# Mark as unread
curl -X PATCH "https://yeti-jobs.onrender.com/api/v1/notifications/{notification_uid}/read?isRead=false" \
  -H 'Cookie: token=<your_jwt_token>'
The controller checks that the notification exists and belongs to the authenticated user before making any changes. If the notification is already in the requested state, the API responds with 200 and a message like "Notification is already marked as read" without performing an update.

Sample Notification Response Object

A single item from the GET /api/v1/notifications/all response array:
{
  "uid": "f4e3d2c1-0000-0000-0000-000000000050",
  "type": "application_status",
  "created_at": "2025-07-11T08:15:00.000Z",
  "read_at": null,
  "job_id": "a3f2c1d4-89ab-4e56-b123-000000000001",
  "company_id": "b7e1a2f3-0000-4cde-9876-000000000099",
  "users_id": "c1d2e3f4-0000-0000-0000-000000000010",
  "job_title": "Senior Backend Engineer",
  "company_name": "Yeti Technologies"
}
FieldTypeDescription
uidUUIDUnique identifier for the notification.
typestringOne of the ten notification type values.
created_attimestampWhen the notification was created.
read_attimestamp | nullnull if unread; set to the read timestamp after marking as read.
job_idUUIDThe associated job (joined to produce job_title).
company_idUUIDThe associated company (joined to produce company_name).
users_idUUIDForeign key to the recipient user in the users table.
job_titlestringDenormalized job title from the jobs table join.
company_namestringDenormalized company name from the companies table join.

Database Schema

CREATE TABLE notifications (
  uuid        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  users_id    UUID REFERENCES users(uid) ON DELETE CASCADE,
  company_id  UUID REFERENCES companies(uid),
  job_id      UUID REFERENCES jobs(uid),
  type        notification_type_enum NOT NULL,
  created_at  TIMESTAMP DEFAULT now(),
  read_at     TIMESTAMP
);
The read_at column doubles as both a boolean read flag and a timestamp: when null the notification is unread; when populated it records exactly when the user acknowledged it.

Build docs developers (and LLMs) love