Notifications

How the platform tells you things — the feed, delivery channels, and per-event preferences.

When something happens that you should know about — a training finishes, a deployment fails, a goal alert fires, your credit balance runs low — the platform emits a notification. Three pieces decide what you actually see:

Event        → something happened (training.completed, deployment.failed, …)
Preferences  → whether it fires for you, and on which channels
Channels     → where it lands: the in-app feed, email, Slack, Teams,
               PagerDuty, or your own webhook

Every notification also lands in your feed — a per-account inbox you can list, filter, and mark read over the API.

Thirty seconds of API

# What's unread?
curl "$API_BASE/v1/notifications/?unread=true" \
  -H "Authorization: Bearer $TOKEN"

# Route critical events to your own webhook
curl -X POST "$API_BASE/v1/notifications/channels" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "webhook",
    "label": "Ops receiver",
    "config": { "url": "https://ops.example.com/hooks/predictai", "secret": "whsec_…" }
  }'

Notifications are account-level, not workspace-level: no X-Workspace-Id header is needed anywhere in this section.

In this section

Concepts

What generates a notification, and channels vs preferences.

Read the feed

List notifications, mark one read, mark all read.

Live stream

Push new feed items over Server-Sent Events.

Channels

Deliver to Slack, Teams, PagerDuty, or your own webhook.

Preferences

The event catalog, and muting or rerouting per event.

For structured live platform events — training progress, deployment status, goal alerts as data — use Realtime (WebSockets) instead of the notifications feed.