New posts land on your WordPress site, on the cadence you set.
The content engine writes through the REST API your site already exposes, using a WordPress user and an application password. Approve each piece first or let the cadence run hands off, and watch your site's status on the Website view.
What do I need to connect my site?
One WordPress user with publishing rights and an application password for that user. Issue the password from the user's profile inside WordPress; it is separate from the login password, and you can revoke it there whenever you choose. Our team stores the credential during setup and tests it before anything is written. The test tells a firewall block from a wrong password, and a page that answers but is not the REST API from both, so a bad connection is named before it costs a post.
Install nothing. There is no plugin, no theme change and no sign-in flow on your side. The site keeps running exactly as it did.
What lands on my site when a piece publishes?
A finished post: title, body, and the featured image uploaded to your media library and attached. The piece has already passed research, writing and the draft stage and been approved, by a person on your TruLata team or by the standing instruction set for your account. It goes up as published, not as a WordPress draft, because the approval step is the review. The post's ID and address are recorded against the piece, your TruLata team is told, and the Content view shows the piece as posted with a link to the live post. If the site refuses the request, the piece drops back to approved for a retry; nothing is lost.
Every external link is checked first. A dead link is unwrapped to plain text, and a piece with more than half its citations dead is held and not published. If the check itself cannot run, the piece publishes and the failure is logged for the team.
Do I approve every piece, or does it run on its own?
Either, set per client. The number of blogs, research papers and press releases a month is set with you, and those pieces are queued at the start of each month. With approval on, nothing publishes until a person has approved the draft, and the Content view shows what has gone up. With hands-off publishing on, the runner picks a topic biased toward the service your existing posts cover least, researches and writes it, attaches the image, publishes live and reports.
Hands-off publishing is an explicit allowlist. A client who wants to read every post first is never placed on it. Before each hands-off run the connection is tested again, so a firewall that has started blocking the API is heard about that day, not after a season of silence, and no research and writing cycle is spent on a post that cannot land. Every piece is also filed as a Google Doc in your Drive folder as it is written. The content engine, and with it this connection, is on Launch, Growth and Command.
My host runs a security plugin. Will that break it?
The blocks these plugins cause are known ones, and each has a path around it. Sucuri, Wordfence and several managed hosts block the pretty /wp-json/ path while leaving WordPress's own ?rest_route= form open, so the connection is stored in that form and every call uses it. Some hosts reject non-browser clients before WordPress sees the request; the publisher identifies itself as a browser. Some block media uploads but not posts; where the site has a separate origin address, the image upload retries there.
The featured image is re-encoded to JPEG before upload unless it carries real transparency, so your site is not asked to derive every thumbnail size from a multi-megabyte PNG. If an upload is still refused, the words publish and the missing image is logged as an error for the team to fix. A post is never held hostage by a picture.
What do I see about my site in the Command Center?
A card for your live site on the Website view, with its status rows and a button that opens the site. Beside it sit the photo folders, the change request box that sends a logged request to your team, and the list of recent updates. None of that edits the site. The only thing the product writes into WordPress is a post from the content engine, with the featured image that post needs; the person who edits your pages is a person. WordPress sites keep their own editor. The separate editor on the pages for the static sites we host is for those sites. The write paths from the screen are listed on the Security page; the content engine's post is the one write this connection adds.
Not on WordPress? Publishing takes the site's own path. The static sites we host slot the post into the site's data, regenerate the affected pages and redeploy, so the public site stays static. A platform with no publishing API, Squarespace for example, keeps the piece at approved until a person pastes it in and records the live address, which moves it to posted.
What the WordPress connection reads and writes.
| What | Where it comes from | How fresh |
|---|---|---|
| Posts | WordPress REST API, wp/v2/posts | On approval, after the link check |
| Featured image | Your media library, wp/v2/media | At publish |
| Credential | WordPress user with an application password | Tested at setup and before every hands-off run |
| Site status | Website view, status rows and open button | With the dashboard |
| Edits to your pages, theme, plugins or users | None from the product | Made by a person on request, never by the product |
The content engine creates posts, and nothing else in the product writes to your site: no settings, no pages, no plugins, no users.
Questions, answered.
Do I need to install a plugin?
No. The connection is a WordPress user with an application password, used against the REST API that WordPress already exposes.
Does it publish as a draft or live?
Live, once approved. The approval step your team takes is the review, so the post is not parked as a WordPress draft waiting for a second sign-off.
Can I keep approving every post myself?
Yes. Approval is a per-client setting. Nothing publishes until a person has approved the draft, and hands-off publishing is switched on deliberately, per client, never for a client whose posts are read first.
What if my firewall blocks the API?
The connection test says so and names the firewall where it can. Clear the block by allowing the REST API or our server's address, or use the ?rest_route= form the site still answers.
Can the product change my pages, theme or plugins?
No. The only writes into WordPress are a new post from the content engine and the media record for its featured image. Page changes are requests to your team, made by a person.
My site is not on WordPress. Can it still publish?
Yes, by the site's own path. Static sites we host publish by regenerating and redeploying. A platform with no publishing API keeps the piece at approved until a person pastes it in and records the live address.
See it running
before you decide.
The demo is the real product on a fictional company, with no form in front of it. Pricing is three published tiers. Setup on your own accounts takes two to four weeks.
Open the live demo See pricing
New here? See what the Command Center is. Prefer to write? Send us the one thing you want to know.
- Refreshed when you open itLive data on page load, never a monthly PDF
- Counted from your own formsLeads recorded server-side, compared daily with Ads and GA4
- Four answer engines, measuredChatGPT, Gemini, Claude and Grok, with a published denominator
- A review-first queue on every sendEvery draft waits in a review-first queue and every send is logged.