# Communications Backend

## Purpose

The communications API provides product-focused endpoints for parent messages and internal alerts without exposing the generated CRUD routes directly to the frontend workflow.

Parent messages reuse existing backend tables:

- `messages`
- `message_recipients`

Internal alerts use:

- `communication_events`

## API

All routes require JWT authentication.

- `GET /api/communications/parent-messages`: returns parent messages created by the current user.
- `GET /api/communications/parent-messages?category=<category>`: filters the current user's parent messages by category.
- `POST /api/communications/parent-messages`: creates one sent parent message and recipient log.
- `GET /api/communications/events`: returns internal alert events visible to the current user's organization and campus scope.
- `GET /api/communications/events?type=<type>`: filters events by type.
- `POST /api/communications/events`: creates one internal alert event.

## Access Rules

- Authenticated tenant users can create and list their own parent-message logs.
- Communication manager roles can create internal alert events.
- Tenant-wide roles can list all organization events.
- Campus-scoped users list events for their campus when a campus is available on their profile.

## Data Contract

Parent message create fields:

- `recipientName`
- `messageText`
- `category`

Event create fields:

- `title`
- `date`
- `type`
- `roles`

The frontend does not send organization, campus, creator, or updater fields. The backend fills them from the authenticated user.