← All posts

Problem and fix

Concrete CMS has a REST API: what it can and cannot do

Concrete CMS ships a REST API in core, it does more than its reputation suggests, and the obvious way to connect to it is the wrong one. A client-credentials token — an ID and a secret, no browser — returns a signed token that reads the site perfectly and then refuses every single write with a 403. The route that works is the one where you approve the integration on your own site. Everything below was found by installing Concrete 9.5.5 on a real address and driving its API; every line was a request and an answer.

Published 20 October 2026 · Last updated 20 October 2026

This is the most useful thing we have written about any platform, because it is the one where the documentation and the behaviour part company most sharply — and because the fix is not a workaround. The supported route is also the better one.

The grant that works, and the one that looks like it does

Concrete offers four OAuth grants. Client credentials is the natural choice for a product talking to a site without a person present, and it appears to work: the token is issued, it is signed, and it reads public pages happily. Then every write comes back with a permission error about adding pages beneath a parent page, which reads like a configuration problem and is not.

The reason is in Concrete's own middleware: it attaches a user to the request only when the token carries a user id, and a client-credentials token has no user on it — Concrete's OAuth client entity has no service-account field to bind one to. So the request runs as the guest, who may read public pages and nothing else. That is Concrete working as designed, not a misconfiguration, and no amount of permission-tinkering will change it. The supported answer is the authorization code grant: the site owner signs into their own Concrete, approves the integration, and the token is bound to them. Their permissions become its permissions, no password reaches us, and they can revoke it from their own dashboard.

1. In the Concrete dashboard, go to System & Settings → API and switch the API on.
2. On the same screen, tick Authorization Code and Refresh Token. Not Client Credentials — it will appear to work and then refuse every change.
3. Under API → Integrations, add an integration with the redirect address shown to you, and copy the Client ID and Client Secret. The secret is shown once.
4. Paste both in. You are sent to your own site to press Approve, and brought straight back.

A Concrete page has no body

This is the part that reshapes everything. A Concrete page has a name, a description, a type and a template — and no body field. The content lives in blocks inside named areas, so writing text means adding a content block to an area, which on a themed page is usually the one called Main. Anything built for Concrete that assumes a body field will not work, and the failure will look like a field name being wrong.

And every content write opens a draft. Adding a block to a published page does not change the published page: it creates a new unapproved version and leaves the old one serving. The same is true of a title change. Reading the page back immediately afterwards returns the approved version, so a successful write looks as though nothing happened at all until you ask for the recent version specifically. Publishing is a separate call that approves the version. That maps onto draft-then-publish more honestly than most platforms manage — and it means your unpublished work is visible to us and ours to you, which is the right way round.

What our Concrete adapter will attempt

7 of 14, which is the lowest on our list alongside Strapi, and they are the ones that matter most. Both halves below are printed from the adapter when this page loads.

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.

What we ran, in one session

Concrete 9.5.5 on PHP 8.3, on an address of our own. A page created, written to, retitled, published, read on the public web, and deleted again.

What Concrete's API does not have

• No taxonomy. Concrete's topics are attributes and nothing exposes the trees, so categories and tags cannot be read or written at all.
• No navigation. Concrete builds menus from the page hierarchy with an autonav block, and there is no endpoint that moves a page in that hierarchy.
• No SEO fields, and no redirects. Reading SEO information works; writing it does not, because Concrete does not offer those fields through its API. There is no redirects endpoint either.
• No list of page types. There is no endpoint for them, so your own type handles can only be learnt from pages that already use them — which means we can report what is in use and not what exists.