WordPress's REST API supports custom fields through register_rest_field(), which attaches a named field to an object type (post, user, comment, term) with get_callback and update_callback functions. The result is a clean REST contract for headless clients, but the WordPress admin doesn't know any of it. The post list shows title and date; the registered my_custom_score field that drives the front end sits invisible until someone reads it through the REST API or writes admin column code.

SleekView introspects the REST schema and exposes every registered field as a candidate column on the relevant object's table. A posts view can show registered REST fields alongside title and author; a users view can show registered REST user fields alongside role and registration date. Filters work against the resolved REST values, and sorts use whichever underlying meta key or table column the field's get_callback reads.

Inline edits route through each field's registered update_callback, which is the same path the REST API itself uses. Any authentication and permission logic the callback applies (capability checks, custom validation) runs the same way for inline edits as it does for REST writes. The view is admin-only and read-only by default; inline editing is opt-in per column and only enabled where an update_callback is present.

The WordPress REST API has been a stable contract for nearly a decade, and register_rest_field() is the canonical extension point. Plugins use it. Themes use it.

Headless front-end teams use it heavily. The result is a rich REST schema on most modern sites that the WordPress admin doesn't reflect at all. A post list still shows title and date, while the registered my_custom_score or category_lock fields that drive the front end sit invisible behind their callbacks.

Headless teams launch with REST contracts they can read but not audit. Editorial teams update REST-driven fields through one-off plugin UIs or by asking developers to write column code per project. Platform engineers track schema coverage by writing throwaway WP-CLI scripts during launches.

SleekView reads the same REST schema registry the API uses and surfaces every registered field as an admin column. Resolvers run through get_callback, writes run through update_callback, permissions and validation behave exactly as they do for REST requests. The schema stays in code where it belongs; the admin finally matches the contract the rest of the stack already follows.