Publish an Article Straight to the WordPress Site You Already Run
How to push a finished draft in the content app directly to your existing WordPress site, or to any other CMS, without changing where your blog actually lives.
Most teams don't want a new place to host their blog — they want a faster way to write for the site they already have. The content app's CMS Publish panel is built around that assumption: it doesn't replace WordPress, Webflow, or whatever else you're running today. It sends a finished article to it.
Two ways to connect
There are two provider paths, and which one you use depends on what you're publishing to.
WordPress is the direct path. You give it your site URL, a WordPress username, and a WordPress application password (not your login password — WordPress issues these separately under Users → Application Passwords). The article gets sent as a POST to {your-site}/wp-json/wp/v2/posts, authenticated with HTTP Basic Auth built from those two values. Title, HTML content, excerpt, and slug all map over directly, and you choose whether the post lands as a WordPress draft or goes straight to published — that's a separate setting from the article's status inside the content app.
Generic is for everything that isn't WordPress: a Webflow CMS API, a custom endpoint your own team built, anything that accepts a POST or PUT with a JSON body. You supply the endpoint, pick the method, and optionally an API key plus which header it should ride in — most APIs want it as Authorization: Bearer ..., but you can point it at a different header name if your endpoint expects something else. The payload sent is title, slug, HTML, a summary, tags, and category, plus any extra fields you want appended for endpoints with their own required shape.
What actually happens when you click publish
The route fetches the article's current content, then makes the outbound call to whichever provider you picked. If WordPress rejects the post — bad credentials, a plugin blocking the request, whatever — you get the actual error message WordPress sent back, not a generic failure. Same for a generic endpoint: a non-2xx response comes back with the status code and the first couple hundred characters of whatever the endpoint said, so you're not left guessing whether it was auth, validation, or something else entirely.
On success, you get back the published URL and the external ID WordPress or your endpoint assigned — useful if you're keeping track of what's been pushed where.
Who can do this
Publishing to an external CMS is gated at a higher bar than general editing: you need to be at least a Manager on the workspace. Writing and editing a draft only requires write access, but sending it to a site the public can see is treated as a separate, more consequential action — see the companion piece on why that sign-off exists if you're setting up roles for your team.
Why this matters more than it sounds like
The alternative most content tools offer is "publish into our system, then figure out how to get it onto your actual site." That's an extra step, and it's the step most teams never finish — the draft sits finished and unused because nobody wired up the export. Publishing directly into the CMS you already run means the AI-assisted draft and the live post are the same action, not two.