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
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.
HEADLESS_SECRET_TOKEN is a single shared secret, and the admin pages hand it to the
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
- 01Upload headless.zip to the /wp-content/plugins/ directory
- 02Extract the Plugin to a headless Folder
