Reference

Notifications

4 routes, generated from Morse’s own OpenAPI document. Every path below hangs off the base URL, and every one needs the bearer header.

The examples are built from each route’s schema, so the shapes and types are exactly what the API declares. The values are illustrative, and no one has run them.

Yours alone: the user id comes from the session, never from the request.

GET/notifications

GET/notifications

curl "$MORSE/notifications" \
  -H "Authorization: Bearer $MORSE_TOKEN"

200

{
  "items": [
    {
      "at": "…",
      "body": "Annual plans are billed up front.",
      "href": "https://onmorse.com/priya",
      "id": "3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60",
      "kind": "…",
      "meeting_id": "3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60",
      "read": true,
      "title": "Pricing review"
    }
  ],
  "unread": 1
}

Empty your bell.

DELETE/notifications

Yours alone, and gone for good: a notification is news, and news nobody wants again is not worth an archive and a way back from it.

DELETE/notifications

curl -X DELETE "$MORSE/notifications" \
  -H "Authorization: Bearer $MORSE_TOKEN"

Every unread one, as the bell closes.

POST/notifications/read

One call rather than one per item: the bell marks them read as a group, and a partial read is not a state anything shows.

POST/notifications/read

curl -X POST "$MORSE/notifications/read" \
  -H "Authorization: Bearer $MORSE_TOKEN"

A nudge that your bell changed.

GET/notifications/stream

No payload; the bell refetches, so one event can never disagree with what a reload would show.

GET/notifications/stream

curl "$MORSE/notifications/stream" \
  -H "Authorization: Bearer $MORSE_TOKEN"