Notifications

Feed scope

The feed is scoped to the current user and their active company (current_company_id): the list, the counter, and "mark all" return only notifications for the active company; marking a single notification read resolves it by the owning user regardless of company.

Notification object

A notification object has these fields:

• id — a UUID string.
• type — a snake_case string identifying the notification kind; the platform currently emits deal_assigned and deal_task_assigned, and the set will grow.
• title — a short heading.
• body — a string or null.
• data — an object whose fields depend on type (e.g. deal_id/deal_title for deal_assigned).
• read_at — the ISO timestamp when read, or null while unread.
• created_at — when it was created.

List response shape and query parameters

Important about the list response shape: GET /v1/notifications returns the standard Laravel paginator envelope — the array under the data key, with the pagination meta fields (current_page, per_page, total, last_page, next_page_url, etc.) sitting flat at the top level. This differs from most REST groups, where a list comes back as data:{ items, pagination }.

Query parameters: filter=unread (return only unread; any other value or omitting it returns all) and per_page (page size, default 20). Note the snake_case per_page (not perPage).

Platform notifications (`GET /platform-notifications`)

GET /platform-notifications (2026-08-24) — not to be confused with the personal "bell" feed above: this is a company-scoped (not per-user) flat log of technical notices from the AISAR platform itself (currently only "channel disconnected", from NotifyChannelDisconnectedJob), replacing the old service-conversation mechanic in chat. It requires the conversation.view permission (the same one the /conversations family uses), the feed window is the last 90 days, newest first, page-based pagination (page/limit, limit 1-50, default 20; a pagination block {page, perPage, total, lastPage}). Rate limit: 120 requests per minute.

A list item: id, kind (the notification type, e.g. channel_disconnected), reason (a human-readable cause, or null), created_at, channel ({id, name, type} or null — null once the channel has since been deleted; the event itself survives), conversation_id and message_id (kept for backward compatibility with notifications inherited from the old mechanic; null on new rows). The feed has no per-item "read" mark — instead, PATCH /me/ui-preferences with aisar_notifications.seen_until (an ISO datetime or null) advances the unseen-cursor consumed by the counters.aisar_notifications key in the Conversations group (GET /conversations/counters).