Security activity
End-user Security is account history (audit events for that user). Internal logs stay on System for operators — they are not a second feed on /security.
Related: Logs architecture · Cache architecture · Security overview.
Endpoints
| Method | Path | Behavior |
|---|---|---|
GET | /me/activities | Paginated audit trail for the current user |
GET | /me/activities/:id | Owner-only detail (email deep links) |
List reads a per-user audit index in Durable Objects (audit:userindex:{userId}); Neon remains source of truth for detail and rebuild-on-miss.
SPA: /security recent table, /security/activities, /security/activities/:id. Deep links are path only — /security/activities/:id. No ?id= / ?request=. Optional ?activities=true scrolls the Security page to the recent table.
Login success and fail use distinct audit actions (login_password_success / login_password_fail, plus OTP / backup-code / OIDC variants). Login-alert email CTAs use /security/activities/:id when the audit write returns an id.
Admin may list another user’s activities at GET /users/:id/activities (permission-gated). That is not the self Security feed.
The old GET /me/security/logs internal-log list for me was removed — unused after the activity feed shipped.
Related
- Logs architecture — operator internal logs (
/system/logs) - Cache architecture
- Ownership — retention policy for the instance