EN
Most people who have to work in a CMS never chose to. They are communications officers, HR advisors or office managers, and something simply needs to go on the website. Umbraco has a pleasant backoffice — but every backoffice asks you to learn where the buttons are, and for someone who shows up twice a year that is just a nuisance.
Since Umbraco 14 that is no longer a given. This is the story of four vacancies that arrived as a Word document and ended up on our site without anyone having to open the backoffice.
Umbraco 14 rebuilt the backoffice from scratch, and that had a consequence that sounds technical but works out very practically: the new backoffice is itself a client of an API — the Management API. Every screen an editor sees talks to that same API under the hood.
That removes an entire category of discussions. With a CMS whose API was bolted on afterwards, the question is always: is this field in there too? In Umbraco the architecture already answered it. Whatever a human can do in the backoffice, a program can do too — not because someone wrote an integration for it, but because it is the same door. Umbraco also ships a machine-readable description, an OpenAPI specification, so you never have to guess how a page is put together.
Umbraco 15 made it usable for integrations. That version introduced the API user: a user without a password, who cannot sign in to the backoffice and only fetches a token on behalf of a system. Beyond that it is an ordinary user — it belongs to a user group and has exactly the permissions you grant it, down to page level.
Concretely: a request came in to refresh the vacancies on our own site. Four of them, delivered the way these things usually are — as one Word document, each vacancy a heading, some running text and a bullet list.
The classic route: someone opens the backoffice, duplicates an existing vacancy, pastes the text across, checks the formatting, and repeats that four times. An hour or two of work, and exactly the kind of job where you forget a block on vacancy three.
The route we took instead: the Word document went to an AI agent with access to an API user, with the instruction to use an existing vacancy page as the example. The agent reads the document, reads through the API how such a page is built — which blocks, which fields, in which order — and lays out the new vacancies in that same structure.
This, for us, is the best part. Writing through the Management API is not the same as publishing. If you update a page through the API that is already published, Umbraco stores it as a pending change: visitors keep seeing the old version, and in the backoffice the new version sits ready for review. Only when a human hits publish does it go live.
That puts the division of labour exactly right. The machine does the work humans are bad at: transcribing accurately, keeping structure consistent, forgetting nothing. The human does the work machines are bad at: judging whether this is what we want to say. And because the API user has its own role, you can confine it to precisely the corner of the site where it is allowed.
Honesty belongs here, otherwise this turns into a brochure. Three things still needed attention:
In other words: today this is not a button anyone in the organisation simply presses. It is a way of working that we set up. But the direction is clear, and the time saved was not subtle.
Fair question, because WordPress can do this too — up to a point. The REST API has been in core since version 4.7 back in 2016, and application passwords since 5.6. Anyone saying WordPress has no API has not looked.
The difference comes down to two things. Coverage: the WordPress API knows posts, pages, media and users, but the very things that make a site its own are not in there by default. Custom fields via ACF are switched off in the API by default. Custom content types have to be exposed explicitly. And a page built with a page builder such as Elementor sits in the database as one sealed blob: technically readable, practically not editable. So an agent hits the wall at exactly the point where a site gets interesting. Permissions: an application password always inherits the full permissions of the user who created it. You cannot narrow an integration down to a single content type; the common advice is a separate user with the lowest possible role, and those roles are coarser than what you can set in Umbraco.
The full comparison is in Umbraco vs WordPress: an honest comparison.
Anywhere content comes from another system or from a document handed to you, this route is interesting: vacancies, product information, location details, events, price lists. The pattern is always the same — the source already exists somewhere, and someone is retyping it.
If your site runs on Umbraco 15 or higher, you already have everything you need and nothing has to be bought. If it runs on 13 or older, this is one of the reasons to make the step to the current LTS.
Curious what this would save on your site? Let us know via the form below, call +31 10 270 75 75 or email hallo@admix.nl.
Adres
Postbus
Curious what this means for your site? Leave your details and briefly describe what you're running into, and we'll get back to you. We usually respond within one business day.
Prefer direct contact? Feel free to call or email us.
The Management API arrived in Umbraco 14: since then the backoffice itself runs on that API, so anything an editor can do, an integration can do too. For integrations without a human behind them you need an API user, and that arrived in Umbraco 15. If you run 15 or higher, everything is already there.
A backoffice user without a password, who cannot sign in to the backoffice and only fetches a token on behalf of a system. Beyond that it is an ordinary user: it belongs to a user group and has exactly the permissions you grant it — which sections, which pages, which actions. That way an integration allowed to update only vacancies really cannot do anything else.
No, and that is exactly the safety valve. When an integration updates a page that is already published, Umbraco stores it as a pending change: visitors keep seeing the old version until an editor publishes in the backoffice. Writing and publishing are two separate actions, and you can withhold the publish permission from the API user.
Partly. WordPress has had a REST API in core since version 4.7 and built-in application passwords since 5.6, so integrating is possible. The difference is coverage and permissions: custom fields (ACF) are off by default in the API, custom content types have to be exposed explicitly, and content from a page builder such as Elementor sits in the database as one block. On top of that an application password always inherits the full permissions of its user, whereas an Umbraco API user gets its own fine-grained role.
They do — but the right things. The retyping and the formatting disappear; the judging stays. In practice the work shifts from entering to reviewing and publishing, and that is exactly the split you want: the machine is accurate, the human decides whether the message is right.