Connect a CMS

Articles publish through the cms category, and WordPress ships in the integration catalogue ready to import. The connection needs four things, all found inside WordPress itself: the site URL, a user with the right role, an application password for that user, and a permalink scheme that gives each article its own path.

The site URL

The catalogue asks for it before anything else: the site root, with no trailing path. If WordPress is installed in a subdirectory, the subdirectory is part of the root, so a site at https://example.com/blog enters exactly that.

Everything runs through the WordPress REST API, which lives under /wp-json on that host. To check it is reachable before you connect, open https://example.com/wp-json/ in a browser: a reachable API answers with a wall of JSON that names your site in its first line. A login page, a 404, or an ordinary web page means the API is not at that address, and the connection has nothing to talk to.

A user that can publish

Connect as a user with the Editor or Administrator role. Publishing alone needs less, but publishing is not all the connection does: an article carries its tags and categories, and a featured image is uploaded to the media library. An Author can publish posts and even create tags, but WordPress refuses to let one create a category, so a publish that carries a new category fails partway on a permissions error.

The application password

WordPress will not accept your account password over the REST API at all. What it accepts is an application password: a separate credential generated per application, precisely so it can be revoked without touching your login.

Generate one in WordPress under Users → Profile → Application Passwords: name it, and copy the password it shows you, because it is shown once. WordPress displays it in groups of four with spaces between them; the spaces are cosmetic, and the password works with or without them.

Three mistakes, one identical error

A publish rejected with 401 You are not currently logged in means one of three things, and WordPress will not tell you which: the account password was used where the application password belongs, the application password was mistyped, or the site is a hosted plan whose tier does not expose REST writes (on the hosted service, that starts at the Business tier). Check them in that order.

Permalinks

Set Settings → Permalinks to Post name, or any scheme that puts the article’s name in its path. This is not cosmetic. Analytics attributes traffic to an article by matching its path exactly, and the plain scheme gives every post the same path, the site root, with only a query string to tell them apart. Query strings are not part of a page’s identity to an analytics provider, so under the plain scheme every article’s traffic lands in one indistinguishable heap.

Pick the scheme before publishing, and then leave it alone: the published URL is how an article is recognized by everything that measures it, and changing the scheme later orphans the history.

Connect it

1. In Settings → Integrations, import WordPress from the catalogue. It asks for the site URL up front.
2. Open the integration and create a connection: the username, and the application password as the password. Settings first, credentials second; the credential is stored encrypted and never shown again.
3. On the Categories tab, verify the proposed bindings and activate them. For a read operation the verify makes a real call while you watch, which is where a wrong URL or password surfaces. For a write operation like publishing, nothing is sent before you activate: the verify renders the exact request that would go out and checks its shape against a sample you provide.

Two cms.post.publish bindings, both active, is the correct end state, not a mistake: WordPress publishes an article it has never seen by creating a post, and one it already holds as a draft by updating that draft in place. Their samples differ in one field. The first verifies with {"title": "T", "content": "B"}. The second addresses an existing post, so its verify needs a sample naming one, as in {"title": "T", "content": "B", "externalId": "1"}; no call is sent, so the id does not have to exist yet.

Canonical URLs

A post published here is its own canonical location, and CommandChain does not send a canonical tag: WordPress core has no canonical field, and the tag belongs to your SEO plugin, under whatever key that plugin uses. If you run one, nothing more is needed; the plugin marks the post canonical where it lives.

Next steps

• Publish an article: the whole path, from draft to measured.
• Connect analytics: so traffic lands on what you publish.
• The integration registry: credentials, bindings, and what verify actually does.