REST API

There are two different things:

The wpmcf attribute

For each field group with Show in the REST API turned on (field group editor, Settings), the values appear under wpmcf on the REST API of every post type named by the group's location rules.

Turning it on

1. Open the field group, Settings, switch on Show in the REST API. It is off by default.
2. The group needs at least one location rule of the form Post type is equal to X. The attribute is added to the endpoint of each such post type. Rules of other kinds (page template, taxonomy, user role, ...) do not add endpoints; only Post type == X does.
3. Password fields are never included in reads and cannot be written.

A post type that no REST-enabled group names has no wpmcf attribute (verified for pages when only posts were named).

Reading

GET /wp-json/wp/v2/posts/42

{
  "id": 42,
  "wpmcf": {
    "listing": {
      "price": 9.5,
      "tags": ["red"],
      "details": { "city": "Rome" },
      "bio": null
    }
  }
}

• Keyed by group key, then field key. Every value field of the group is listed; a field with no value is null.
• Values are the PHP values wpmcf_get_field() returns (numbers as numbers, checkbox as an array, groups as objects, repeaters as arrays of rows, images as attachment IDs).
• password fields and password sub-fields are left out.
• The same data is returned for context=view and context=edit.
• It follows the post's own REST visibility. In the view context a password-protected post returns an empty wpmcf ([]) for logged-out and ordinary requests; with context=edit (needs edit_post) the values are returned (verified).
• It works in collections (/wp/v2/posts?search=...) and with _fields=id,wpmcf. _fields cannot narrow below wpmcf.
• Reading the attribute needs no extra capability: a logged-out visitor can read the values of a published post, exactly as they can read the post. Do not turn the setting on for groups whose values must stay private.

Writing

POST /wp-json/wp/v2/posts/42
Content-Type: application/json

{ "wpmcf": { "listing": { "price": "19.25", "tags": ["red", "blue"] } } }

Also works with PUT/PATCH and when creating a post (POST /wp/v2/posts with a wpmcf object).

Rules (all verified):

// From PHP, with the WordPress HTTP API and an application password.
$response = wp_remote_post( 'https://example.com/wp-json/wp/v2/posts/42', [
    'headers' => [
        'Authorization' => 'Basic ' . base64_encode( 'user:application-password' ),
        'Content-Type'  => 'application/json',
    ],
    'body'    => wp_json_encode( [ 'wpmcf' => [ 'listing' => [ 'price' => 450000 ] ] ] ),
] );

// In the block editor or an admin script.
apiFetch( { path: '/wp/v2/posts/42', method: 'POST', data: { wpmcf: { listing: { price: 450000 } } } } );

Schema

OPTIONS /wp-json/wp/v2/posts lists wpmcf in the schema with type: object, context: ["view", "edit"], one object per group and one property per field. Property types are intentionally loose because the field type sanitizes the value:

Limitations

• Posts only. Users, terms and comments have no wpmcf attribute (use the PHP functions or the post-meta bridge).
• Top-level fields only; to change one sub-value send the whole container.
• Groups attached to a post type through rules other than Post type == X are not exposed.
• No per-field permissions; every value of the group is readable and writable under the rules above.

The wpmcf/v1 namespace

/wp-json/wpmcf/v1/... is the API of the plugin's React admin screens: field groups, post types, taxonomies, options pages, Global Data, settings, tools, onboarding and Health. It is internal: routes, parameters and responses can change in any release, and it is not intended for integrations.

Permissions (verified for several routes with four kinds of requests):

Every route has a permission_callback (a capability, plus a license check for Pro routes) and an args schema. Nearly all require manage_options; only the block editor routes require edit_posts (see Blocks and Block Bindings). There is no admin-ajax use. Cookie authentication needs the X-WP-Nonce header (wp_create_nonce( 'wp_rest' )) like every WordPress REST request; application passwords work too.

Route groups in this version:

Do not call these from a theme or another plugin. To create or change definitions from code, use PHP-registered groups or import JSON (see Field groups); to read or write values, use the functions in this section or the wpmcf attribute.