Reading values

Pro

Every exposed post, term or user response gains a vx object next to WordPress's own fields:

curl "https://example.com/wp-json/wp/v2/books/123"

{
  "id": 123,
  "slug": "the-glass-library",
  "title": { "rendered": "The Glass Library" },
  "vx": {
    "tagline": "A novel of lost catalogues",
    "price_range": { "value": "$$", "label": "$$" },
    "author_name": "Elena Voss",
    "photos": [
      { "id": 88, "url": "https://example.com/wp-content/uploads/cover.jpg", "alt": "The cover", "title": "Cover", "caption": "", "mime": "image/jpeg" }
    ],
    "writers": [
      { "id": 200, "type": "writer", "title": "Elena Voss", "url": "https://example.com/writers/elena-voss/", "vx": { "role": "Author" } }
    ]
  }
}

What's in it

• Keys are field keys, or the field's REST key when you set one.
• Only fields the current viewer may read are included. A hidden field is left out completely, rather than sent as null, so a response never reveals that a field exists.
• An entry with nothing exposed returns "vx": {}.
• Choice fields return both the stored value and its label. Media fields return an object with the file's address and details. Relations return a short reference for each linked entry.

The field formats table lists the exact shape for every field type.

Linked entries

Each linked entry comes with its id, type, title, address and, where the viewer may see them, its own vx fields. That nesting goes two levels deep: fields of a linked entry are included, but that entry's own links are plain references. A relation lists at most 100 linked entries.

Private uploads

For a file uploaded with private uploads, viewers who can't access the file get "url": null. The rest of the file's details are still included.

Password-protected posts

A published post with a password hides its vx values from visitors, the same way WordPress hides the post's content. To read them, pass the password with WordPress's own password parameter:

curl "https://example.com/wp-json/wp/v2/books/123?password=the-secret"

Users who can edit the post always see the values.

Collections

Collection requests work exactly as in WordPress, and each item carries its own vx object:

curl "https://example.com/wp-json/wp/v2/books?per_page=20&page=2"

per_page is capped at 100. Use WordPress's _fields parameter to return only what you need: ?_fields=id,title,vx.

Caching

Responses are cached separately for each access tier, for up to five minutes. Editing an entry, or changing what's exposed, clears the cache straight away. Editors, and requests with context=edit, always get fresh data.

Technical details for LLMs

• Node kinds: scalar (string / number / boolean / date string; choices → { value, label }), object (named children), list (values, { value, label }, media objects or row objects), media ({ id, url, alt?, title, caption?, mime }; audio adds duration; url null for inaccessible private uploads), relation ([ { id, type, title, url, vx? } ], depth 2, 100 refs).
• Empty/unexposed → vx: {}; unreadable fields are omitted. Raw meta registered with show_in_rest is stripped from context=view for non-editors.
• Password-protected: non-editors get vx: {} unless ?password= matches (timing-safe); such posts bypass the response cache for non-editors.
• Cache: per-tier, TTL 300 s, key rotated on content or exposure-config change; editors and context=edit bypass. When vxframework/rest/can_read, vxframework/rest/field_value or vxframework/rest/resource_response is hooked, authenticated-tier payloads are computed live.
• per_page cap: vxframework/rest/max_per_page (default 100). Output contract version 1 (reported by vx-framework/v1/rest/schema).