Skip to main content

Overview

The Alerts API provides notification and calendar event management functionality. It supports creating alerts with different severity levels, scheduling notifications, and managing calendar events. Alerts can be marked as read and support time-based scheduling.

Endpoints

Get Alerts

Retrieves all alerts for the authenticated user.

Response

Alert[]
Array of alert objects

Example Request

Example Response


Create Alert

Creates a new alert or notification.

Request Body

string
required
Title/subject of the alert
string
required
Detailed message content
string
default:"info"
Alert severity: ‘info’, ‘warning’, or ‘critical’
boolean
default:"false"
Initial read status (typically false for new alerts)
boolean
default:"false"
Whether this is a calendar event
string
When the event is scheduled (ISO 8601 format)
string
When to send the notification (ISO 8601 format)

Response

Alert
The newly created alert object

Example Request - Simple Alert

Example Request - Scheduled Event

Example Response


Update Alert

Updates an existing alert’s details.

Path Parameters

integer
required
The ID of the alert to update

Request Body

Accepts the same fields as Create Alert (all optional for updates):
string
Updated title
string
Updated message
string
Updated severity level
boolean
Updated read status
boolean
Updated event flag
string
Updated scheduled time
string
Updated notification time

Example Request


Delete Alert

Deletes an alert from the system.

Path Parameters

integer
required
The ID of the alert to delete

Example Request

Error Responses

success
Alert deleted successfully
error
Alert not found
error
Unauthorized - Authentication required

Mark Alert as Read

Marks a specific alert as read.

Path Parameters

integer
required
The ID of the alert to mark as read

Example Request

Response

Returns success status (typically 200 OK).

Alert Types

The system supports three severity levels:

Info

  • General notifications and informational messages
  • Calendar events and reminders
  • Status updates
Use cases:
  • Scheduled maintenance windows
  • Upcoming inventory audits
  • System announcements

Warning

  • Important notifications requiring attention
  • Non-critical issues
Use cases:
  • Low stock alerts
  • Upcoming loan due dates
  • Expiring items

Critical

  • Urgent notifications requiring immediate action
  • System errors or failures
Use cases:
  • Out of stock items
  • Overdue loans
  • Failed system operations
  • Security alerts

Business Logic Notes

Alert vs Event Distinction

  • Alerts (isEvent: false): Notifications about system states or issues
  • Events (isEvent: true): Calendar-based items with specific scheduled times
  • Events typically have both scheduledAt (event time) and notifyAt (notification time)

Notification Scheduling

  • scheduledAt: When the actual event occurs
  • notifyAt: When to notify the user about the event
  • Example: Event at 9 AM, notification at 8 AM (1 hour advance notice)
  • Backend should implement a notification service to process notifyAt times

Read Status Management

  • Alerts are created with isRead: false by default
  • Use the dedicated /alerts/{id}/read endpoint for marking as read
  • This provides better audit trails than direct updates
  • Consider implementing bulk “mark all as read” functionality

Date Format

  • All timestamps use ISO 8601 format with timezone information
  • Always include timezone (typically UTC) in API requests
  • Client should convert to local timezone for display

Automatic Alert Generation

Consider implementing automatic alerts for:
  • Low stock thresholds (when inventory falls below minimum)
  • Overdue loans (daily check for loans past expectedReturnDate)
  • Upcoming loan due dates (1-3 days before expectedReturnDate)
  • Scheduled maintenance or audit reminders

Alert Lifecycle

  1. Created: Alert is generated (manual or automatic)
  2. Delivered: Notification sent to user (via push, email, in-app)
  3. Read: User acknowledges the alert
  4. Archived/Deleted: Alert is removed after a retention period

Performance Considerations

  • Implement pagination for alerts list (can grow very large)
  • Consider soft deletes for audit purposes
  • Archive old read alerts after a retention period (e.g., 30 days)
  • Index on isRead and createdAt for efficient querying

UI Integration