calendar

The caller's own calendar feeds, newest first - never anybody else's, whatever the role: a feed is a credential its owner holds, and an administrator who could list them could subscribe to them. The token is not among the fields. It is shown once, when the feed is created, and stored only as its hash; a feed whose token was lost is revoked and made again.

Mints a feed over one saved view, and answers its token and its URL - once. The token is stored as a hash keyed on the installation secret under its own purpose label, so it can never be replayed as a page cursor, a media token or a personal access token, and the stored value cannot be turned back into the token. The feed reads as its owner reads, evaluated at every fetch: an owner who loses access to half the view sees the feed narrow with them, and a revoked membership is not survived by a token that remembers better days.

Revokes the feed. The row stays with the moment it was revoked - which is what makes "this token was revoked on Tuesday" answerable - and every fetch from that moment on is a 404 in exactly the words an unknown token produces. Somebody else's feed is not found rather than forbidden, for the reason every other read of somebody else's thing is.

The calendar, as RFC 5545. Gregorian whatever the subscriber's display calendar, with an all-day due date as a VALUE=DATE entry and a timed one carrying its own zone so that it stays put across a daylight saving transition. Minimal by default: the title, the dates and a link back, never the notes - the restraint a notification email keeps applies here for the same reason, since a calendar entry is read on devices and screens nobody in this workspace controls. An unknown token, a revoked one, a feed whose view has been deleted and a feed whose owner has lost the view all answer the same 404 with the same body. Distinguishing them would answer questions to whoever is trying tokens.