Notifications

Namespace notifications (actionstools_app/notifications/), table em_actions_notifications (_staging outside production), key (target_uuid, uuid). Unlike the rest of the API, request and response bodies use camelCase; notification_model maps them to the snake_case attributes in DynamoDB.

All routes need X-Actions-TargetUUID and X-Actions-TargetType. Listing and updating also check, through the Payability internal API, that the user may read/update that supplier (SupplierReadUpdateValidator).

Method Path Behaviour

GET

/notifications/

Newest first. At most one of ?createdAfter=<iso datetime>, ?isRead=true|false, ?isHidden=true|false; more than one is a 400. meta.count counts the same query.

POST

/notifications/

{"notificationType", "notificationContent", "issuer"} → 201. Created unread and visible.

PATCH

/notifications/

Batch: [{"uuid", "isRead"?, "isHidden"?}, …​].

PATCH

/notifications/<uuid>/

{"isRead"?, "isHidden"?}; at least one is required.

notificationContent in the response model maps to the notification_type attribute (notifications/models.py), so responses currently echo the type in both fields. Fixing it changes the API contract for existing clients.