Read the browse layouts this install offers
GET /browse-views
The layouts the operator has enabled, in the switcher’s canonical order. The frontend fetches this once at boot and renders only these buttons — and, more importantly, filters every rung that can name a layout through this set: the device’s stored choice, the signed-in account’s default, and the coarse-pointer default. A user whose browser still remembers a layout the operator has since disabled therefore lands on one that is offered rather than on an empty page.
Read separately from the admin GET /admin/system/browse-views
rather than folded into it because the caller is every visitor,
not the operator: this one carries no capability check and is
cached as a single install-wide entry.
An install that has never configured this returns all five. The set is never empty — the write endpoint refuses that, and this endpoint falls back to all five if it somehow reads one anyway, because an empty answer here would mean a browse page with no way to look at anything.
GOVERNED BY PUBLIC MODE (#445), like /previews: anonymous on a
public install, 401 on a private one. It is deliberately NOT
excused the way /appearance and /site-text are — those two
render the login card, so an install that refused them
anonymously could not draw its own sign-in page, whereas the
first consumer of this is the browse switcher, which on a
private install is already behind auth. A logged-out visitor
browses only where anonymous browse exists, and that is exactly
where this answers. The registration and the full reasoning live
in auth.PublicSurfaceRoutes — that table, not this
description, is what the gate actually reads.
What it exposes on a public install is which layout buttons the install draws: no asset, no user, no access decision, and nothing a caller could not read off the rendered switcher.
Responses
Section titled “ Responses ”The enabled layouts, in canonical order
object
The browse layouts this install offers, in the switcher’s canonical order. The server reorders whatever it is sent into that order and drops duplicates, so layout order stays a frontend decision and only availability is the operator’s.
MUST NOT BE EMPTY. A write enabling nothing is refused with a 400 and nothing is persisted — an install offering no layout has an unreachable browse page, and the recovery path would be a database shell.
An install that has never configured this reads back all five. That is the shipped default expressed as the absence of a stored value, not as a seeded row.
Example
[ "grid", "list", "feed"]