What the WordPress REST API can and cannot change

Anything that drives WordPress from outside — a script, a headless front end, an AI assistant, a deployment pipeline — is limited by the same thing: the REST API only exposes what core registered a route for. There is no general "run this in WordPress" endpoint. If a route does not exist, no amount of cleverness on the client side reaches that part of the site.

This is the most useful thing to know before building anything against WordPress, and it is usually discovered halfway through instead. So here is the line, drawn plainly.

What core REST covers

More than its reputation suggests. The content endpoints landed in core in WordPress 4.7 (December 2016), and the API has been extended almost every year since.

Read that list again if your mental model of the REST API is "posts and pages". On a block theme, the whole design layer is reachable: templates, template parts, navigation, and the global styles object that holds colours, typography and spacing. That is most of what people mean when they say they want to change how a site looks.

Custom post types and taxonomies are in only if they were registered with show_in_rest set to true. That is the single most common reason a route that "should" exist returns rest_no_route — the type exists in WordPress and was never opted into the API.

Where core REST stops

Short list, and each item stops for the same reason: nobody registered a route.

• Switching the active theme. /wp/v2/themes reads. It does not write. There is no core endpoint that activates a different theme.
• Running updates. Core, plugin and theme updates have no REST route. /wp/v2/plugins installs and activates from wordpress.org, but it does not update anything.
• Customizer values and theme mods. On a classic theme, the entire Customizer layer — including Additional CSS — lives in theme mods with no REST representation.
• Most options. /wp/v2/settings exposes a small allowlist: site title, tagline, timezone, date format, posts per page, the front-page configuration and a few more. An option some plugin stored is not reachable unless that plugin registered it.
• Permalink structure and image sizes.
• Cron, transients and caches.
• Custom fields that were not registered with show_in_rest, including most ACF setups by default.
• Anything a plugin does in wp-admin without registering a route of its own.

Uploading and activating a plugin from a ZIP is on that list too — /wp/v2/plugins installs by slug from wordpress.org only, which is why a connector cannot install its own companion plugin for you.

Why the line falls there

Not an oversight, and mostly not laziness. Registering a REST route means committing to a schema, a permission callback, and backward compatibility more or less forever. Core has been deliberate about which surfaces get that commitment, and the ones it skipped tend to be the ones that can break a site outright — switching a theme, updating core, rewriting permalinks.

The practical consequence for anything built on top: the ceiling is the same for everyone. A headless front end, a deployment script and an AI connector all hit exactly the same wall, because the wall is in WordPress, not in the tool. When you read that some integration cannot switch your theme, that is not a missing feature in the integration.

The two things that move the line

A plugin that registers routes. This is the old answer and still the common one. Anything with a REST route becomes reachable, which is why plugin-based integrations can do more on the sites they are installed on.

The Abilities API, which landed in core in WordPress 6.9. It is a standard way for core and plugins to declare a named, schema-described, permission-checked capability — run this, here is what it takes, here is who may do it — instead of each plugin inventing its own route shape. Abilities are discoverable, so a client can list what a site can do rather than hard-coding assumptions, and it is the extension point the WordPress project is building its AI work on.

This matters for the ceiling because an ability can cover things REST never did. A plugin can register switch the theme or run the pending updates as an ability with a real permission callback, and a client that speaks abilities reaches it without a bespoke route per feature.

wpreef's approach to the gap is exactly that: an optional plugin, wpreef-bridge, that registers abilities for theme switching, updates, Customizer values, settings, permalinks, image sizes, cron and caches — with each group switched off until you turn it on. Everything in the tool list not marked as a companion ability works over core REST with nothing installed. The split is not marketing; it is this table.

Deciding what you actually need

Work backwards from the task rather than from the feature list.

Most content work sits above the line. Most maintenance work sits below it. That split explains why "manage my WordPress site with AI" is two different products depending on which half of the job you meant, and why it is worth being precise about which half you need before choosing anything.

Questions people ask

Can the WordPress REST API switch the active theme?

No. /wp/v2/themes is read-only: it lists installed themes and reports their support flags, but core registers no route that activates one. Theme switching requires a plugin that registers its own route or a WordPress Ability that does it.

Can the WordPress REST API update plugins or core?

No. Core, plugin and theme updates have no REST endpoint. /wp/v2/plugins, added in 5.5, can install a plugin from the wordpress.org directory and activate or deactivate an installed one, but it does not run updates and cannot install from an uploaded ZIP.

Why does my custom post type return rest_no_route?

Because it was registered without show_in_rest. A post type or taxonomy is absent from the REST API entirely unless it opts in, so the route genuinely does not exist. Add 'show_in_rest' => true to the registration, and set rest_base if you want a different path.

Can I change Customizer settings over the REST API?

Not on a classic theme. Customizer values are stored as theme mods and core exposes no route for them, including Additional CSS. Block themes are different: their design lives in global styles at /wp/v2/global-styles, which is fully readable and writable.

What is the Abilities API and does it replace REST?

It is a core API, added in WordPress 6.9, for declaring named capabilities with an input schema, an output schema and a permission callback. It does not replace REST — it sits above it as a discoverable, uniform way for core and plugins to expose what a site can do, including things core REST never registered a route for.