Notifications

The notification commands read and manage the connected account's own notification centre. All commands are account-scoped and require --account (or a default set via curviate config set-account).

Both writes (delete, show-less) are self-actions — they act only on the account's own cards and never notify or touch a third party. notification list is a read (no --preview; passing it is a usage error, exit code 2). The writes are --preview-capable and, following the destructive-write convention (see post / job close), have no confirmation prompt — their idempotent, reversible-in-spirit semantics make one redundant. Every command supports --json (automatic when stdout is not a TTY) and --fields.

Commands

# List your notification cards, newest first (paginated read)
# --filter selects one stream (default all):
#   all | jobs | mentions | my_posts | my_posts_comments |
#   my_posts_reactions | my_posts_reposts
curviate notification list [--filter <stream>] [--limit <n>] [--cursor <token>] [--all] [--max-pages <n>]

The list carries the account-level unread_count (the unseen badge — not a count of items) and latest_published_at (a cheap poll watermark). Injected/promo cards are included and flagged (injected: true), never filtered out. This feed throttles hard under fast polling — poll unread_count rather than deep-paging.

{
  "object": "NotificationListPage",
  "items": [
    {
      "card_urn": "urn:li:fsd_notificationCard:(urn:li:fsd_notification:9999,ALL)",
      "object_urn": "urn:li:activity:7290000000000000000",
      "headline": "Jane Smith commented on your post",
      "injected": false
    }
  ],
  "cursor": "eyJ…",
  "unread_count": 3,
  "latest_published_at": 1730000000000
}

# Delete one of your own notification cards (write, --preview accepted)
# Pass the card_urn (urn:li:fsd_notificationCard:(…)) from a `notifications
#   list` item — NOT its object_urn (that targets the wrong notification).
# The urn embeds ( ) : , — pass it raw; the CLI percent-encodes it.
curviate notification delete <card_urn>

# "Show less like this" on one of your own cards (write, --preview accepted)
# For a network-activity card this removes the card (LinkedIn exposes no
#   softer signal). Same card handle, idempotency, and timing as delete.
curviate notification show-less <card_urn>

Write behavior

Both writes take the card's entity urn — the card_urn field of a notification list item (urn:li:fsd_notificationCard:(…)), never its object_urn. They are idempotent: deleting (or show-lessing) a card that is already gone succeeds; only a card_urn that never existed on this account returns RESOURCE_NOT_FOUND. They are effective within a few seconds for an organic card (network activity — a repost/comment/reaction by your network). A list re-read immediately after a write may still show the card for a moment — that is not a failure signal.

Caveat — editorial/promotional cards. delete is honest about its limit here: LinkedIn most likely re-injects editorial/promo cards, so a 200 is a correct accepted-request response, not a guarantee the card stays gone. Use show-less to suppress promo content — it is the reliable path for those classes.

Examples

List unread activity

curviate notification list --account acc_YOUR_ACCOUNT_ID

List one stream

curviate notification list --filter mentions --account acc_YOUR_ACCOUNT_ID

Preview a delete before sending it

curviate notification delete "urn:li:fsd_notificationCard:(urn:li:fsd_notification:9999,ALL)" --preview --account acc_YOUR_ACCOUNT_ID

Delete an organic card, or suppress a promo card

# Delete a network-activity card
curviate notification delete "urn:li:fsd_notificationCard:(urn:li:fsd_notification:9999,ALL)" --account acc_YOUR_ACCOUNT_ID
 
# Suppress a promotional card (delete may not stick; show-less is reliable)
curviate notification show-less "urn:li:fsd_notificationCard:(urn:li:fsd_notification:8888,ALL)" --account acc_YOUR_ACCOUNT_ID