Skip to content

Home

The Home feed is the app's landing surface: a fixed sequence of six curated sections. It is editorially assembled, not algorithmic — editors decide what appears, with two sections drawing automatically. Home is configured from a single CMS screen (the Home settings record) and stands in for the eventual Home content type (CSL-42).

The six sections

Section order is fixed and known to the FE (not user-reorderable). An empty non-mandatory section renders nothing and the FE closes the gap; the hero is the one mandatory section (its absence is a page error, not an empty state).

# Section How it's populated Endpoint Status
1 Today's Quote (hero) Automatic — all Passages eligible, fresh per session, anti-repetition client-side GET /api/passages/todays-featured/ Live
2 Featured Journeys Editorial — pin → Featured Journeys list → skip (≤5) — Planned
3 Theme of the Week Editorial — one editor-set theme + label; supplies the page wash GET /api/themes/featured/ Live
4 What's New Editorial + auto — editor pins first, then newest eligible Articles/Writings (cap 10) GET /api/whats-new/ Live
5 Featured Books Editorial — the editor's manual list order (cap 10) GET /api/books/featured/ Live
6 Further Reading (a.k.a. What's Trending) Automatic — random over essays + letters — Planned

One endpoint per section

Home is served as one endpoint per section, not a single aggregate call: most of Home sits below the fold, so the FE loads the hero first and the rest lazily / in parallel, and each section carries its own cache window. Every section endpoint is public, app-key–gated, user-agnostic, and cacheable; per-user state (bookmarks, progress) is overlaid by the FE from the /api/account/ endpoints.

See also

  • API Guide — the endpoint map and per-section API behaviour.
  • Editor Guide — how editors configure Home in the CMS (pins, eligibility, order, limits).
  • Journeys & Home — the design/history record (slot model, rationale); not operational guidance.