Access tiers
Pro
Each field resolves to one of three access tiers:
| Tier | Who sees the value |
|---|---|
| Public | Anyone who can read the entry itself, logged in or not |
| Authenticated | Logged-in users who can read the entry |
| Private | Only users who can edit the entry |
A field set to Inherit from fieldset uses the fieldset's default, which is Private unless you change it. So a new field is never public by accident.
Who is asking
| Viewer | Receives |
|---|---|
| Not logged in | Public fields, on entries the public can read |
| Logged in, can't edit the entry | Public and Authenticated fields |
| Can edit the entry | Every field except passwords |
The last row is why the block editor always works: editors need every value. It's also why an administrator's own requests are a poor test of what visitors get; use Preview on the REST API screen instead.
Rules that always apply
- Entry visibility comes first. A public field on a draft or private post is only visible to people who can see that post.
- Password-protected posts hide their
vxvalues from visitors, just as WordPress hides the content, until the request includes the right password. See Reading values. - Links are checked on both ends. When a field links to another entry, that entry's fields are included only if the same viewer may see them, so a public post can't reveal a linked user's private details.
- User fields top out at Authenticated. A user field marked Public is still only served to logged-in viewers.
- Password fields are never served, to anyone.
- Private uploads don't have their file address served to viewers who can't access them.
Groups and repeaters
Access is decided for the top-level field. A Group or Repeater is exposed or hidden as a whole: its sub-fields follow the container's tier, even if you set a stricter tier on one of them. Keep sensitive values out of a public Repeater by putting them in a separate top-level field or fieldset.
A container that holds a password field anywhere inside it is never served below editor level.
The REST API only
Access tiers control what the REST API returns. They don't affect dynamic tags or Bricks tags: a field you bind in a public template is shown to everyone who sees the page.
Technical details for LLMs
- Resolution: field
rest.access→ (inherit) fieldsetrest.expose→ defaultprivate. Viewer tiers: anonymouspublic; logged-in non-editorpublic+authenticated; editor exemption (edit_post/edit_term/edit_user) sees all non-sensitive fields. - Hard exclusions:
is_sensitive()types (password), non-data types,rest_bindable() === falsetypes (area). Containers with a sensitive descendant are withheld (and their raw meta) below editor level. - Relation boundary: nested refs re-evaluate access against the target with the same viewer; depth cap 2, 100 refs per field.
- Users: served only for opted-in roles, never anonymously, capped at
authenticated. - Override decisions with
vxframework/rest/can_read(sensitive exclusion can't be lifted).