What the WordPress REST API Can and Can’t Reach in a Page-Builder Theme

The REST API is the fastest way to inspect and fix a WordPress site at scale – until you hit a page-builder theme and half your changes vanish into a store the API never mentions. Knowing where that line falls, before you start, is the difference between an afternoon of clean edits and an afternoon of confusion.

What standard REST exposes – and it’s most of the site

The core content model is fully REST-addressable, and for most launch and cleanup work that is the whole job:

• Posts and pages – /wp/v2/posts, /wp/v2/pages: read, create, update, change status. Demote a demo post to draft, publish a real page, fix body content.
• Menus and menu items – /wp/v2/menus, /wp/v2/menu-items: read every item’s URL and rewrite the broken ones.
• Taxonomies – /wp/v2/categories, /wp/v2/tags: rename, merge, or delete leftover demo terms.
• Settings – /wp/v2/settings: title, tagline, the designated privacy page, the posts-per-page count, and the “discourage search engines” flag.
• Media – /wp/v2/media: confirm featured images exist and carry their full size ladder. (When they don’t, that is its own REST quirk worth knowing.)

The one piece people assume is off-limits but isn’t: the front page’s page-builder blocks. A static front page is a normal Page, so a builder’s shortcodes or block markup live in that page’s content field. Read it with context=edit and you can see – and fix – the demo category blocks and banner ads a theme demo plants there.

If the content sits in a post or a page, the REST API can reach it. The trouble starts where a builder keeps its data somewhere else.

Where the REST API stops: the builder’s own store

Page-builder themes keep two important things outside the post table, and standard REST registers neither:

1. The theme options panel. Footer copyright, the “about” blurb, social links, logo, and global colors are saved as one big serialized option (a single wp_options row). The core API exposes only a short allow-list of settings, and these are not on it.
2. The cloud / template library. The header, footer, and archive layouts are stored as a custom post type the theme registers privately. Because it is not marked show_in_rest, it never appears under /wp/v2/, and its bodies are usually base64-encoded on top of that (which is a design choice with real trade-offs).

So the exact residue that makes a demo look unfinished – the “Made with <Theme>” footer, a demo logo, a sample social bar – is precisely the residue standard REST can’t see. That is not a bug in the API; it is a boundary. The API is authority over WordPress’s content model, and this data lives in the theme’s model.

How to tell what’s reachable before you start

Rather than guessing, probe the boundary once:

# Is this post type exposed to REST at all? An empty/404 answer means "no".
curl -s "https://your-site/wp-json/wp/v2/types?_fields=slug,rest_base"
# What settings does core actually expose? (short allow-list)
curl -s -H "Authorization: Basic $APP_PW" "https://your-site/wp-json/wp/v2/settings"
Code language: Bash (bash)

If the template post type isn’t listed, or the value you want to change isn’t in settings, it is on the far side of the wall – plan for a snippet. (If those authenticated calls fail with a 401 rather than returning data, that is a separate multisite auth issue, not a reachability limit.)

Bridge the gap with a read-only snippet

The clean way across the wall is a small read-only REST endpoint, registered by a code-snippet plugin (operator-activated), that returns exactly the theme options and template bodies you need to inspect – base64-decoded so you can read them – and nothing else. Read widely; locate the precise demo string; then change it with a one-time setter snippet that writes fixed values and runs once – matching the exact form the encoded body stores, or the replace silently no-ops.

The temptation is to skip a step and build a “set any option over REST” endpoint. Resist it. A general writer that takes an option name and a value as input is a backdoor, not a tool – anyone who finds it can change anything. If you are already reaching for a snippet, prefer one that does a named, hardcoded job. (On when a snippet beats a full plugin at all, see code snippet versus plugin.)

Read broadly with a read-only endpoint; write narrowly with a one-shot snippet. The general write API is the one you never want to leave installed.

This same boundary is what makes a theme demo-content cleanup a two-part job: the REST-reachable core, fixed directly, and the theme’s own store, bridged deliberately.

The short version

In a page-builder theme, the WordPress REST API reaches everything in the content model – posts, pages, menus, categories, settings, and the front page’s builder blocks (because the front page is a Page). It does not reach the theme options panel or the cloud template library, which live outside post_content in theme options and an un-exposed custom post type. Probe /wp/v2/types and /wp/v2/settings to see the boundary for yourself. To change what is past it, add a read-only snippet to locate the values and a one-time setter snippet to write them – never a generic option-writer, which is a security hole.

Frequently Asked Questions

Can I edit my theme’s footer or logo through the REST API?

Usually not with standard REST. Footer text, logo, and social links are saved in the theme options panel as a single serialized option, and the core API exposes only a short allow-list of settings that does not include them. You reach them with a code snippet, not /wp/v2/.

Why can I edit the front page but not the header or footer template?

The front page is a normal Page, so its builder blocks live in that page’s content field, which REST exposes. The header, footer, and archive layouts are stored in the builder’s own template library – a custom post type that isn’t registered for REST – so they never appear under /wp/v2/.

How do I check whether a post type is available over REST?

Request /wp-json/wp/v2/types and look for the type’s rest_base. If the type isn’t listed, it wasn’t registered with show_in_rest, so the core API can’t read or write it. A private theme template type is the common example.

Is it safe to add a REST endpoint to change theme options?

Add a read-only one freely – it can only leak what an admin already sees, and you can gate it to logged-in admins. Avoid a write endpoint that accepts an arbitrary option name and value: that is a general backdoor. Make each change with a hardcoded, run-once setter snippet instead.

Does this apply to block themes and full-site editing too?

The specifics differ – full-site-editing templates are exposed through the wp_template endpoints – but the principle holds: content lives in REST-addressable post types, while a theme’s own configuration store may not be. Always probe /wp/v2/types and /wp/v2/settings before assuming a value is reachable.