We built against eleven CMS APIs: what each one will and will not let an AI do
We have written adapters for 11 content systems and driven each one's official API. The short version: every one of them can be read, created in, edited and published to, and the differences that matter are all at the edges — SEO fields, menus, scheduling and redirects. 6 of 11 can write SEO metadata. 3 can reach a menu. 1 can manage a redirect. The whole table is below, printed from the adapters rather than typed, which is the only way a table like this stays true for longer than a week.
·
This is the post we would have wanted before starting. Every platform's documentation describes a capable API; none of them says plainly what it leaves out, and some of them describe things that do not work the way the page implies. What follows is what we found by building against each one.
The table
14 jobs down the side, 11 platforms across the top. Each platform links to its own page, where the same information is broken down further and where the verification state of each row is recorded.
| What you can ask for | WordPress | Joomla | Drupal | Craft CMS | Concrete CMS | Ghost | Webflow | Wix | Contentful | Strapi | Sanity |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Read content | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Create content | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Edit content | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Publish content | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Schedule content | Yes | Yes | No | Yes | No | Yes | No | Yes | Yes | No | No |
| Manage images and files | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Manage categories and tags | Yes | Yes | Yes | Yes | No | Yes | Yes | Yes | Yes | No | No |
| Edit SEO information | Yes | Yes | No | No | No | Yes | Yes | Yes | No | No | Yes |
| Manage menus | Yes | Yes | Yes | No | No | No | No | No | No | No | No |
| Custom content types | Yes | No | Yes | Yes | Yes | No | Yes | Yes | Yes | Yes | Yes |
| Bulk changes | No | No | No | No | No | No | No | No | No | No | No |
| Site information | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Manage redirects | No | No | No | No | No | No | No | Yes | No | No | No |
| Administrative information | Yes | Yes | Yes | No | No | Yes | Yes | Yes | Yes | No | Yes |
This table is generated from the adapters when the page loads, not typed out. A green cell means the software will attempt that job on that platform; a grey one means it refuses before it tries, because the platform offers no supported way to do it. Bulk work is the one row that is empty for every platform: no adapter claims it yet, and the automation page says so too.
How to read it: a green cell means our software will attempt that job on that platform through its official, supported API. A grey cell means it refuses before trying, because the platform offers no supported way to do it. Grey is never a judgement about the platform — Webflow has no menu API because menus live in its Designer, which is a reasonable decision by Webflow and simply a fact we have to work with.
Five patterns in the table
Read the whole grid at once and the same five things come up, whichever platforms you happen to care about.
- Reading and writing are solved everywhere. All 11 can list content, read one in full, create something new, change it and publish it. If what you want is an assistant that drafts and edits, the platform barely matters.
- SEO metadata is the great divide. 6 of 11 expose SEO fields at all: WordPress, Joomla, Ghost, Webflow, Wix and Sanity. On the others there is nothing to write into — not a permission we lack, no field in the API.
- Menus are almost nobody's. 3 platforms can reach navigation: WordPress, Joomla and Drupal. Everywhere else a menu is either part of the design, or a feature of a plugin whose storage is its own business.
- Scheduling splits the hosted from the self-hosted, but not the way you would guess. 6 can set a future publication date: WordPress, Joomla, Craft CMS, Ghost, Wix and Contentful. Some of the most modern platforms here cannot, because they treat a future publication as a separate feature rather than a field on a page.
- Redirects are a near-total blank. 1 of 11: Wix. On most platforms a redirect belongs to a plugin, a hosting layer or a configuration file, and none of those is an API.
Four things that were not in any documentation
These are the findings that cost real time, and the reason this post exists rather than a summary of eleven feature pages.
- A Concrete CMS token with no user on it is a visitor. Concrete offers client credentials — an ID and a secret, no browser, the obvious choice for a product like ours — and it works: it returns a signed token and that token reads the site happily. Then every write comes back 403. The reason is that Concrete binds permissions to a *person*, and a client-credentials token has no person on it, so the request runs as the guest. The supported route is the one where the customer approves it on their own site, which is also the better arrangement: no password reaches us, and they can revoke it themselves.
- Wix has no pages API at all. There is no Pages permission in Wix's own permission catalogue and no site-structure API behind it, so a Wix site's pages, menus and navigation cannot be reached by anything outside the Wix editor. The blog, on the other hand, is reachable in full. That is a big enough fact to deserve its own post, and it has one.
- Webflow can write a page's SEO text but not the page. `PUT` on a page writes its title, slug and real SEO fields. The endpoint for a page's visible text refuses the primary language outright — Webflow's own position is that primary-language page content is changed in the Designer. So "Webflow pages cannot be edited" was half right in a way that matters: the words a visitor reads, no; the words Google reads, yes.
- Alt text usually does not live on the image. On Ghost, on Drupal and on Wix, the description of a picture belongs where the picture is used rather than to the file — because the same photograph can mean different things on two pages. Three platforms reached that arrangement independently, which suggests it is right, and it means "upload an image and write its alt text" is one job on some platforms and two unrelated ones on others.
REST, GraphQL, and one that is neither
Most of these are REST APIs. Craft is GraphQL, and its API is core in every edition, including the cheapest — though a new schema can read and not write, because the mutation boxes start unticked and a schema with everything readable and nothing writable fails silently rather than loudly. Sanity is a query language of its own over a content lake, where drafts are separate documents rather than a state on one. Contentful and Sanity are not even at your website's address: your website is whatever you built on top of them, and the thing we connect to is the content store behind it. None of that changes the shape of the table, which is the useful finding — the differences that matter to somebody asking an assistant for something are not the differences the technology press writes about.
What this means if you are choosing
If you are picking a platform *in order to* work this way, the table rewards the old and boring: WordPress and Joomla allow the most, and they allow it through interfaces that have been stable for years. If you already have a platform, the useful question is narrower — which two or three of these fourteen do you actually care about? Somebody who wants an assistant to draft and tidy blog posts is well served almost everywhere. Somebody who wants one to look after menus and redirects across a large site is served by WordPress, Joomla and Drupal and by nobody else, and should know that before buying rather than after.
Honest limit: this table says what each adapter will attempt, which is not the same as what has been proved. 9 of the 11 have had capabilities exercised against a live installation and recorded with a date; the rest are built from each platform's documentation and source, and are marked as untested on their own pages until somebody has watched them work. We would rather publish the weaker claim accurately than the stronger one hopefully.
Questions we get asked about this
- Which platform allows the most?
- WordPress and Wix, at 12 of 14 each, for completely different reasons: WordPress because its REST API covers nearly all of it, Wix because the one part of a Wix site that is reachable is reachable in depth. Joomla is next at 11.
- Why is the bulk row empty for everybody?
- Because no adapter claims it yet. On this product a bulk change is an ordinary edit repeated with a preview and an approval in front of it, and until that is exercised per platform we would rather show an empty row than a promise.
- Do you use anything unofficial to fill the gaps?
- No. No browser automation, no scraping, no undocumented endpoints. If a platform has no supported way to do something, the answer is that it cannot be done, and the grey cell stays grey.
- How often is this table checked?
- It is not checked on a schedule — it is generated from the working software every time this page is loaded, so it is as current as the product. The date at the top of the post is when the prose around it was last gone over.