Notifications

The feed belongs to the authenticated person. Routes need a personal API key; organization API keys are refused. Send org_id when the key can access more than one organization. Entries scoped to another organization are hidden; entries that are not tied to an organization appear under every organization. Responses use the snake_case field names shown below.

GET /api/v1/notifications

curl -H "Authorization: Bearer $AX_API_KEY" \
  "https://app.514.ax/api/v1/notifications?org_id=$AX_ORG_ID&page_size=20"

Query parameters are page_size (default 50, at most 100), cursor (the previous page's next_cursor), and unread_only (true or false). The response is {entries, next_cursor}; next_cursor is null on the last page.

Each entry describes one changed object: event_id, type (for example context.product.updated), schema_version, occurred_at, actor, subject ({type, id}), scope, payload, created_at, and read_at (null while unread). Entries are ordered by occurred_at, then event_id, newest first. Paging with cursor never repeats or skips an entry while new ones arrive; read from the first page again to see entries that arrived since. Expect new type values and fields over time and ignore those you do not recognize.

POST /api/v1/notifications/read

curl -X POST \
  -H "Authorization: Bearer $AX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"event_ids":["<EVENT_UUID>"]}' \
  "https://app.514.ax/api/v1/notifications/read?org_id=$AX_ORG_ID"

Send 1 to 100 event_ids. The response is {marked_count}, the number of entries that changed from unread to read. Ids that are already read or are not in your feed are ignored, so repeating a request is safe.

Connect RPC

AxpNotificationsService exposes ListNotificationFeed (orgId, pageSize, cursor, unreadOnly) and MarkNotificationFeedEntriesRead (orgId, eventIds). Each response wraps the REST body as {result: ...}.