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).

Before you start. You need an API key and a connected LinkedIn account. Run curviate account list to read your acc_... ids; if it returns an empty list, connect an account first (Authentication & Accounts). Without one, every command here exits 4 with ACCOUNT_NOT_FOUND.

The command noun is notification, singular. The plural form is not a command; it exits 2 with unknown command.

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, because 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": "notification_list",
  "items": [
    {
      "object": "notification",
      "card_urn": "urn:li:fsd_notificationCard:(urn:li:fsd_notification:9999,ALL)",
      "object_urn": "urn:li:activity:7290000000000000000",
      "injected": false,
      "type": "COMMENTS_BY_YOUR_NETWORK",
      "text": "Jane Smith commented on your post",
      "actor_id": "ACoAAA...",
      "actor_ids": ["ACoAAA..."],
      "actor_profile_url": "https://www.linkedin.com/in/janesmith",
      "activity_urn_id": "7290000000000000000",
      "read": false,
      "published_at": 1730000000000,
      "target_url": "https://www.linkedin.com/feed/update/urn:li:activity:7290000000000000000",
      "can_show_less": true
    }
  ],
  "cursor": "eyJ...",
  "unread_count": 3,
  "latest_published_at": 1730000000000
}

The preview text is text, not headline; there is no headline field. type is an open enum (SHARED_BY_YOUR_NETWORK, COMMENTS_BY_YOUR_NETWORK, REACTIONS_BY_YOUR_NETWORK, PYMK, WVMP_V2, and others), so pass unknown values through rather than switching exhaustively. read tells you whether the card has been seen; can_show_less tells you whether show-less will do anything. On an injected card, card_urn, object_urn, and type are all null and the card cannot be deleted, so branch on injected before either write.

# Delete one of your own notification cards (write, --preview accepted)
# Pass the card_urn (urn:li:fsd_notificationCard:(...)) from a `notification
#   list` item, NOT its object_urn (that targets the wrong notification).
# The urn embeds ( ) : and , so 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 and 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

Next steps

• Feed: read the home feed the notifications point at.
• Post: react to or comment on the activity a card references.
• Profile: resolve actor_id to a full member profile.
• Errors: the full error-code list and what to retry.