Read a subject's activity

The newest entries recorded against one subject, limit at a time (50 by default, 200 at most), newest first. Name the subject by alias and id:

curl "https://api.example.test/v1/activity?subject_type=project&subject_id=$PROJECT_ID&limit=20" \  -H "Authorization: Bearer $TOKEN"

There is no paging beyond limit: the endpoint is a recent-history read, not an export. The subject is resolved through its own tenant-scoped query before activity is read, so passing the id of a project, client or project member that belongs to another team returns 404 RESOURCE_NOT_FOUND rather than an empty list; existence never leaks across tenants. A project outside the token's scope:project: allow-list is a 404 for the same reason.

• subject_type and causer_type use short morph aliases (project, client, project-member, user) rather than internal class names. Treat them as opaque strings. The subject_type query parameter accepts project, client and project-member today, and every artefact alias as its module lands; anything else is 422 VALIDATION_FAILED.
• actor_kind distinguishes the surface the change came through: human (the app), api_token (REST), mcp (an MCP tool), integration (an inbound delivery such as a Telegram command), webhook, ai (an accepted Heimdall draft) or system (a scheduled job). Filter on it client-side when you need "everything the agent did yesterday" separately from what people did.
• changes holds, for an update, attributes (the new values) and old (the previous ones) of the columns that changed.
• properties keys matching token, secret, password, api_key or api_secret (case-insensitive) are stripped at any depth before the response leaves the server, so a context window never sees credentials that were logged alongside a write.