Headless

Adds features to use WordPress as a headless CMS: extra fields and prepared block content on the REST API, custom routes for menus and site settings, a preview that points at your frontend instead of the WordPress theme, and cache revalidation for frontends that support it.

Configuration

The plugin is configured with constants in wp-config.php:

• HEADLESS_HEAD_BASE_URL — base URL of your frontend. Preview and revalidation requests go here.
• HEADLESS_SECRET_TOKEN — shared token sent to the frontend’s /api/preview and /api/revalidate endpoints.
• HEADLESS_API_KEY_HEADER_KEY and HEADLESS_API_KEY_HEADER_VALUE — require this HTTP header on requests that use the plugin’s REST additions.

Who can read the responses

The plugin’s REST additions activate on requests carrying ?headless=true. That query parameter is a routing flag, not authentication — anyone can set it. Unless you configure HEADLESS_API_KEY_HEADER_KEY and HEADLESS_API_KEY_HEADER_VALUE, the /headless/v1/menus and /headless/v1/settings routes and the added post fields are readable by anyone who can reach your REST API. Configure the API key if that is not what you want.

browser so the editor can open a preview. Every user who can edit posts — Contributor upwards — can therefore read it and use it against your frontend’s preview and revalidation endpoints directly. Treat it as a secret shared with your whole editorial team, and give the frontend its own rate limiting.

Arbitrary section

• BREAKING CHANGE 1.7.0: core/block for block references has changed