WordPress setup

The WordPress connector creates draft posts over the official REST API, authenticated with an application password. There is no plugin to install, and nothing goes live until you publish in wp-admin.

Requirements

• WordPress 5.6 or newer (application passwords shipped in 5.6).
• HTTPS. WordPress refuses application-password authentication over plain HTTP.
• REST API reachable at {your-site}/wp-json/ - the default unless a security plugin blocks it.
• A user with permission to create posts (Author role or above; Editor if BirchSeek should manage categories).

Step 1 - generate an application password

1. Log in to wp-admin as the user BirchSeek should post as - the posts’ author will be this user.
2. Open Users → Profile and scroll to Application Passwords.
3. Enter BirchSeek as the application name and click Add New Application Password.
4. Copy the generated password immediately - WordPress shows it once. It looks like abcd EFGH 1234 ijkl MNOP 5678; the spaces are cosmetic, and BirchSeek accepts it with or without them.

No Application Passwords section? The site is on HTTP, running WordPress older than 5.6, or a security plugin has disabled the feature.

Step 2 - connect in BirchSeek

In onboarding (or Connectors → WordPress later), enter:

Setting	Meaning
Site URL	Your site’s root, e.g. https://example.com
Username	The wp-admin username (not the email, unless your login uses it)
Application password	The value from step 1
Default status	draft (recommended) or publish
Default category	Optional; resolved or created by name

Step 3 - send a test

Send a test makes one read-only call, GET /wp-json/wp/v2/users/me?context=edit, so a wrong username, revoked password, or blocked REST API fails with the site’s own error message. context=edit is the part that matters: it is what makes WordPress return the account’s capabilities, so the same call also proves the user can create and edit posts, and, if you set the default status to publish, that it can publish them. The result names the connected user and says which of those it can do.

The test creates nothing. No post, no draft, no category. The first thing BirchSeek writes to your site is your first approved article.

What BirchSeek writes

Per article, via POST /wp-json/wp/v2/posts:

• title, content (rendered HTML), slug, excerpt
• status - draft by default; your call
• categories and tags - resolved by name, created if missing

content ends with a ## Sources block: a numbered list pairing each verified claim with the page it was checked against, rendered into the HTML like any other section. BirchSeek composes that body once, before any connector sees it, so every connector publishing to your own site writes the same block - there is nothing to append yourself. (A syndicated copy to dev.to, Hashnode or Medium carries the same block, and the canonical link back to your page besides. That copy is not covered by the project setting: those three platforms have no citation field of their own, so the body is the only place the evidence can travel.) The block is on by default, and there is no switch for it in the dashboard: it is a project setting called append_sources_section, and the only way to change it today is PATCH /v1/projects/{id} carrying the whole settings object, because that request replaces the object rather than merging into it.

Yoast and RankMath fields

Yoast and RankMath store their title and description in post meta that is not writable over the REST API by default: WordPress drops meta keys a plugin has not registered for REST. BirchSeek writes core fields only, so neither plugin’s fields are filled in for you.

The meta description does reach the post, as the native excerpt. The meta title reaches WordPress on no field at all - this is the one connector that does not send it. Both values are on the article in BirchSeek, so copy them from the review screen into the plugin’s fields while the draft is open. If your site does register those meta keys for REST, email contact@birchseek.com and we’ll enable direct meta writing for your connection.

Security notes

• The application password is stored encrypted at rest and is used only against your own site’s REST API, for the calls listed here.
• Revoke it anytime in wp-admin (Users → Profile → Application Passwords → Revoke) and access ends immediately.
• BirchSeek reads only where publishing needs it: the credential check above, a lookup of wp/v2/posts by slug before each publish so a retry updates the draft it already made instead of adding a second one, and a search of wp/v2/categories and wp/v2/tags to resolve your terms by name. It reads no other part of your site.

Troubleshooting

• rest_cannot_create - the user’s role can’t create posts. Use an Author-or-above account.
• 401 at connect time - wrong username, or the application password was revoked. Note: some hosts strip the Authorization header; ask your host to allow it (or enable it in .htaccess).
• Categories not applied - the connecting user needs Editor rights to create new categories; existing ones resolve fine for Authors.
• REST API blocked - security plugins (or Cloudflare rules) sometimes block /wp-json/. Allow authenticated requests to wp/v2/users/me, wp/v2/posts, wp/v2/categories and wp/v2/tags.