The WordPress REST API, and what an AI can actually do with it
The WordPress REST API is the interface WordPress uses to talk to itself — the block editor is built on it — and it is also how an assistant like ChatGPT or Claude can read and write your site. It covers more than any other platform we have built for: 12 of the 14 jobs on our list. The two it leaves out are redirects and bulk work, and both are missing for reasons that have nothing to do with WordPress being limited.
·
Most people meet the REST API as an address: `/wp-json/wp/v2/posts`. On a site without pretty permalinks it answers at `/?rest_route=/wp/v2/posts` instead, and that is worth knowing straight away, because the first form returns a 404 on those sites and the 404 looks exactly like the API being switched off.
Where it is, and how to tell it is on
Open `https://your-site/wp-json/` in a browser. A wall of JSON means it is on. A 404 means one of two things — a plugin has switched it off, or your site does not use pretty permalinks — so try `https://your-site/?rest_route=/` before you conclude anything. Our own checker tries both, in that order, for exactly this reason.
That reply also lists the namespaces WordPress has registered, and the list is more useful than it looks. `yoast/v1` means Yoast SEO is installed; `rankmath/v1` means Rank Math is. Our adapter reads it on purpose, because which SEO plugin a site runs is what decides whether SEO fields can be written at all — WordPress core has no meta description of its own to write.
How something is let in
With an application password, which is WordPress's own answer to this question and the best answer any platform here gives. It is a separate credential, made per application, listed in your profile, and revocable on its own without touching your login.
- In WordPress, go to Users → Profile.
- Scroll down to Application Passwords and add one, named after whatever is going to use it.
- Copy it once — WordPress will not show it to you again. It is displayed with spaces in it; the spaces are decoration and can be pasted as they are.
What the API lets an assistant do
12 of the 14 jobs on our list. Both halves below are printed from the WordPress adapter when this page loads, so they are the jobs the software will actually attempt.
What WordPress lets us ask for
-
Read content
-
Create content
-
Edit content
-
Publish content
-
Schedule content
-
Manage images and files
-
Manage categories and tags
-
Edit SEO information
-
Manage menus
-
Custom content types
-
Site information
-
Administrative information
What WordPress has no way to do
-
Bulk changes
-
Manage redirects
Both lists are generated from that platform's adapter when the page loads, so they are what the software will attempt rather than what we would like to say. Bulk work is the one row that is empty for every platform: no adapter claims it yet, and the automation page says so too.
The three things to know before you rely on it
None of these is a reason not to use it. They are the places where "WordPress can do anything" stops being true, and it is better to read them here than to find them out in the middle of something.
- What has an update waiting is not in the REST API. There is no core route that reports which plugins need updating. Ours comes from a small companion plugin, and it reads only — nothing in this product installs, activates or updates anything, which was a deliberate decision rather than an unfinished feature.
- Redirects are not WordPress's. They belong to whichever plugin you use for them, and each one stores them differently. We claim nothing there rather than guessing at one plugin's tables and getting it wrong on a site that uses another.
- SEO fields depend on your SEO plugin. Yoast and Rank Math both expose theirs through the REST API, which is why reading that namespace list matters. A site with neither has no SEO fields for anything to write, and a tool that claimed otherwise would be writing into nothing.
The failure that is not WordPress's fault
A good share of "the REST API is broken" reports are a host's firewall. ModSecurity on shared hosting rejects requests that carry a programmatic user agent, or a full URL in a query string, with a 403 or a 406 — and it does it before WordPress runs, so nothing appears in any WordPress log and the site looks fine in a browser. We send an ordinary browser user agent from our own server for this reason, and we keep full URLs out of query strings. If an API call works from your laptop and fails from a server, this is the first thing to suspect and the easiest to miss.
Honest limit: the lists above are what our adapter will attempt. Whether each job has been watched working on a live WordPress is a stronger claim and a separate one, recorded per capability with the date it was checked, and printed on WordPress AI Agent's own page rather than summarised in a sentence here. And in any case "WordPress works" is not a claim about your WordPress, which may have the API switched off, no SEO plugin, or a firewall in front of it. The compatibility checker answers for your own address in a few seconds.
Questions we get asked about this
- Is the REST API safe to leave switched on?
- Reading is public on a stock WordPress, and what it exposes is what your site already publishes. Writing always needs a credential, and an application password can be revoked from your own profile the moment you want it gone.
- Does an assistant need my WordPress password?
- No, and it should never have it. An application password is a different credential that works only for the REST API, can be deleted on its own, and never changes how you log in.
- Can it edit a page that is already live?
- WordPress allows it, and on this product it needs the publishing permission as well as the writing one. Editing something a visitor can already read counts as changing what visitors see, which is a different box and it starts unticked.