WordPress integration

1. Requirements

• WordPress 5.6 or later (application passwords are built in from that version).
• The site reachable over HTTPS from the internet.
• A user allowed to publish: Editor or Administrator role.
• Permalinks set to anything other than "Plain" (Settings → Permalinks). With plain permalinks the REST API does not answer at /wp-json.

2. Create an application password

In WordPress go to Users → Profile, scroll to "Application Passwords", type a name you will recognise — "Sembalia", for instance — and hit Add.

WordPress shows you a 24-character password with spaces. Copy all of it, spaces included: it is only shown once.

This is not your account password: it is a separate credential you can revoke at any time without changing your login or ending your sessions. If you ever suspect it, delete it and create another.

If you cannot see that section it is almost always because the site is not on HTTPS: WordPress hides application passwords over unencrypted connections. Some security plugins disable them too.

3. Connect it in Sembalia

In the panel, inside your project, go to Settings → publishing target and pick WordPress. Fill in three fields:

• Site URL: the root, e.g. https://yoursite.com (no /wp-admin, no /wp-json).
• Username: your WordPress username, not your email.
• Application password: the one you just generated.

Credentials are stored encrypted with AES-256-GCM. They are never shown again and never written to logs.

4. What it publishes

When a piece goes live, Sembalia does this against your WordPress:

• Uploads the hero image to your media library and sets it as the featured image.
• Resolves categories and tags: it looks each one up by slug and creates it only if missing. It never duplicates one you already have.
• Creates the post with title, HTML content, slug and an excerpt taken from the meta description.
• Stores the post ID. Next time that piece changes it UPDATES that post instead of creating another.

The HTML arrives sanitised: formatting tags only (headings, paragraphs, lists, bold, links), no scripts or event attributes. Contextual links to your pages are already inside the text. Related articles are NOT in the body: they come separately in internalLinks, each with its URL, for you to render wherever you want.

5. About post status

Posts are created already published. What decides WHEN is the Sembalia calendar, not WordPress: we send the piece at the moment your cadence says.

If you would rather review before anything goes out, do not control it from WordPress: put the project in Report mode. Everything gets generated but nothing is published, and you publish by hand from the panel once you have read it.

6. Later updates

A published piece does not stay still. Sembalia touches it again when it rewrites the title from a Search Console proposal, when retroactive linking adds a link to an older article, or when a backlink comes in.

All of that lands on the same post, by its ID. No duplicates appear on your blog.

If you hand-edit a Sembalia-managed piece in WordPress, the next update will overwrite the content. Edit from the Sembalia panel so your changes survive.

7. Troubleshooting

• 401 unauthorised: check the username is the username and not the email, and that you copied the whole application password including its spaces.
• 403 forbidden: the user cannot publish, or a security plugin (Wordfence, iThemes) is blocking the REST API. Add an exception for /wp-json.
• 404 at /wp-json: permalinks are set to "Plain". Change them under Settings → Permalinks and save.
• No application passwords section: the site is not on HTTPS, or a plugin disabled them.
• Publishes without a featured image: your WordPress is refusing the media upload. Check uploads folder permissions and the server upload size limit.
• Duplicate categories: happens if you changed a category slug in WordPress after the first publish. Sembalia looks terms up by slug.
• Nothing arrives and the panel reports an error: your server may sit behind Cloudflare with rules blocking automated requests. Allow ours.

8. Security

• Use a dedicated Editor user rather than your admin account: if anything is compromised, the blast radius is smaller.
• The application password is revoked from your WordPress profile in one click, without touching your real password.
• It is only ever stored encrypted. It is neither shown again in the panel nor written to logs.

Not on WordPress?

If your site is hand-built you need no CMS at all: there is the content webhook, which sends every publication to your endpoint so you can store it wherever you like, and the content API to pull from at build time.