We spent part of a development session treating a WordPress integration layer as if it were the WordPress interface. Then we tested the simpler route: talk to WordPress directly.
The result was a useful architecture correction. For routine content automation, the native WordPress REST API already provided most of what we needed. We kept privileged executable-code deployment separate instead of giving the content automation credential administrator access.
What WordPress already provides
WordPress has a native REST API for content resources including posts, pages, media, categories and tags. It also supports Application Passwords for authenticated external integrations over HTTPS. That means an automation client can use a revocable application-specific credential instead of a human’s interactive WordPress password.
Official references:
What we tested on the real site
We did not treat “the API should support this” as acceptance. We exercised the operations against the site and read the results back.
- Post draft: create returned HTTP 201, update returned 200, read-back succeeded, cleanup returned 200.
- Page draft: create returned HTTP 201 and cleanup returned 200.
- Media: upload returned HTTP 201 and immediate cleanup returned 200.
- Private post and page: both were created with the expected private status and then removed.
- Fleet endpoints: the existing Rose fleet snapshot and command routes remained reachable through the direct client.
Those tests were deliberately reversible. Acceptance artifacts were drafts, private content or temporary media and were removed after verification.
Least privilege mattered more than convenience
The API identity can edit and publish content and upload media. It is not a WordPress Administrator and it does not have plugin-install capability.
That split is intentional. A credential used frequently by automated content workers should not automatically gain permission to install executable PHP. Routine publishing and privileged code deployment are different security domains.
We added idempotency before trusting retries
One subtle problem appears as soon as automation becomes reliable enough to retry failures: what happens when WordPress accepted a create request but the client never received the response?
Blindly repeating the request can create the same article twice. We therefore added a stable request ID and a local operation ledger. In the acceptance test, the first request created a temporary post. Replaying the identical request returned the same WordPress post ID rather than creating another post. The replay was explicitly marked as a replay, and the acceptance post was then deleted.
This is especially important for autonomous systems because a timeout is an ambiguous state, not proof of failure.
What changed in the architecture
The routine path is now deliberately small:
Rose / authorised chat
↓
first-party direct client
↓
WordPress REST API
↓
TokenOptimisation.co.uk
There is no requirement for a third-party middleware service in that normal content path.
We still separate the few operations that WordPress correctly protects more heavily. Installing or replacing executable plugin code remains outside the Editor-level content credential. For Rose-specific server-side capabilities, the plan is a small first-party plugin with its own bounded API, audit trail and signed update mechanism.
Why this matters for AI automation
Every extra service in an automation chain adds another quota, authentication boundary, outage mode and source of human intervention. Middleware can still be valuable when it provides a capability you genuinely need, but it should earn its place in the architecture.
Our revised decision order is:
- Use the native API first.
- Build a small first-party integration for genuine gaps.
- Add third-party middleware only when its value exceeds the extra dependency.
What we have not proved
This is not a claim that every WordPress automation project should remove middleware, nor that the native API covers every administrative operation. Our content credential intentionally cannot install plugins. We also have not published a throughput or cost-saving percentage from this change.
What we can say is narrower and mechanically testable: on this site, the native WordPress REST API successfully handled the routine content operations we tested, while the direct path used no middleware API calls during those acceptance tests.
The useful lesson
Before adding another automation platform, test the system’s native interface. The boring API that has been there for years may already solve most of the problem — with fewer moving parts to monitor, pay for and recover.