Skip to content

Access tiers ​

Pro

Each field resolves to one of three access tiers:

TierWho sees the value
PublicAnyone who can read the entry itself, logged in or not
AuthenticatedLogged-in users who can read the entry
PrivateOnly 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 ​

ViewerReceives
Not logged inPublic fields, on entries the public can read
Logged in, can't edit the entryPublic and Authenticated fields
Can edit the entryEvery 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 vx values 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) fieldset rest.expose → default private. Viewer tiers: anonymous public; logged-in non-editor public + 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() === false types (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).

Documentation for the VX Framework.