Memory Counts
Totals for the dashboard’s type rail (MESH-467).
Scope MIRRORS list_memories — owners and admins see the whole org, plain
members only their own, and legacy org_id IS NULL rows stay visible to
their owner. It has to: a rail that counts rows the list then refuses to
show is worse than no rail, and the shared _visible_memory_scope is what
keeps the two from drifting apart.
Deliberately unpaginated and unfiltered by search. These are the totals the nav shows, so they describe everything the caller can see rather than whatever the current page or query happens to contain — which is the whole reason the dashboard stopped summing the (capped) list client-side.
Authorizations
Enter your MeshAPI key (rsk_...) — sent as Authorization: Bearer <key>.
Headers
Dated version of the API contract to pin this request to. Omit it and the request is served under 2026-08 — the oldest supported version, so an existing integration is never moved by a release. A malformed or unsupported value is rejected with 400 invalid_api_version rather than falling back silently. The version actually served is echoed as X-Mesh-Version on every response, including errors.
2026-08 Response
Successful Response
Org-wide totals behind the dashboard's type rail (MESH-467).
Three different things get counted, because the rail and its subtitle answer three different questions and conflating them is how a nav badge starts lying:
items— rows of each type the caller can see.expired_items— of those, how many are pastexpires_at. Still insideitems: retention lapses on read, so the row is here to be seen and revived until the sweeper hard-deletes it. Guardrails are always 0 — they never carry a deadline.memories_with— how many MEMORIES hold at least one item of the type, i.e. the length of the list the rail's own view will render.
memories is the total the "All memories" row shows. It counts memories,
not items, which is why it is a separate field rather than a fourth key in
items.