FREE PRO
Properties
Models define REST response transformation rules for a post type or taxonomy. Sitewide transforms (resolve embedded data, flatten rendered fields, strip domain from URLs) are available in the free tier and apply globally to all routes. Per-property control (disable, rename or remap individual fields) and custom schemas require Pro.
Transformations run server-side before the response is sent, removing the need for client-side data massaging.
WordPress Schema
The WordPress schema applies the standard WP REST response structure with optional transforms layered on top. Available transforms:
- Relative URLs — strips the domain from attachment and post link fields
- Embedded terms — inlines taxonomy term objects
- Embedded author — inlines the author user object
- Embedded attachments — inlines all post attachments
- Resolve rendered props — unwraps
renderedwrappers (e.g.title.rendered→title) - Remove empty props PRO — strips null and empty string fields
- Remove
_links— removes the HAL links object - Remove
_embedded— removes sideloaded embed data
Per-Property Control PRO
In Pro, each individual property in the WordPress schema can be managed at field level:
- Disable — remove a specific property from the response
- Rename — expose a property under a different key (e.g.
title.rendered→headline) - Remap — source a property's value from a different field in the original response
These rules layer on top of the sitewide transforms and apply to the WordPress schema mode only.
Custom Schema PRO
The custom schema replaces the full REST response with a hand-crafted property map. Define each top-level key you want in the response and map it to a dot-path from the original REST response (e.g. "headline": "title.rendered"). You can also add static values.
Properties in a custom schema support the same sitewide transforms as the WordPress schema:
- Resolve media — replace an attachment ID with the full media object. The resolved object uses the active model you have defined for the
attachmenttype; if none is defined it falls back to the default WP REST response. - Resolve terms — replace term IDs with full term objects. The resolved object uses the active model for that taxonomy; if none is defined it falls back to the default WP REST response.
- Resolve author — replace author ID with the full user object. The resolved object uses the active model for
user; if none is defined it falls back to the default WP REST response. - Filter URL — strip the domain from URL fields (relative URLs)
- Search & replace (under development) — apply text substitutions to string field values
Use this mode to produce a minimal, application-specific payload that hides WordPress internals entirely.
Test
The Test tab fetches a live sample entry from WordPress and displays the raw REST response alongside the transformed result side by side. Use it to verify your schema before deploying — no external request needed.
The test uses the first available entry of the model's object type and runs the full transform pipeline.
Entry type: Model (Post type or Taxonomy)
FAQ
Can I define one model per post type and one per taxonomy?
You can define as many models as you want for the same object type, but only one can be active at a time. This lets you maintain multiple schema variants (e.g. a minimal public schema and a richer internal one) and switch between them without deleting the others.
Do models apply globally or per application?
In Pro, models are scoped per application. The same post type can be served with a minimal public schema to one application and a richer internal schema to another — each application has its own active model per object type. In the free tier, one model per object type applies to all consumers.
Which routes support property-level filtering?
Property-level control (disable, rename, remap, custom schema) currently applies to standard WordPress object routes — posts, pages, custom post types, taxonomies, users, and media (/wp/v2/). The /wp/v2/settings route is also supported: you can pull ACF options pages and resolved menus, and edit the properties of that endpoint.
For other routes (third-party plugin endpoints), you can already explore their schema in the Routes explorer, and fine-grained property filtering is coming very soon. In the meantime, those routes support disable, auth enforcement, rate limiting, and redirect at the route level.