WordPress has included everything an external system needs for publishing since version 5.6: the REST API and application passwords. You create a dedicated user with the role of author or editor, generate an application password for it, and enter both into the blog system. After that, posts appear directly in WordPress with title, text, category and featured image, either as a draft or published, with no extra plugin and no copy and paste.
The usual process looks like this: a text is written in Word or an AI tool, copied into the WordPress editor, the formatting is lost, subheadings have to be set again, the image is uploaded separately, the category is forgotten. Half an hour per post, producing nothing but errors. Yet WordPress has had an interface for years that makes all of this unnecessary.
What the WordPress REST API is
The REST API has been part of the core since WordPress 4.7. It allows programs to communicate with a WordPress installation over the internet: reading and creating posts, editing them, uploading images to the media library, querying categories. The Gutenberg editor itself uses this interface whenever you save a post. An external blog system does the same thing, just without anyone sitting in a browser.
The interface address is always under your domain, for example https://ihre-firma.ch/wp-json/wp/v2/posts. If you open this address in your browser and see a list of your posts in JSON format, the REST API is active.
What you need to prepare
No programming is needed for the connection, but you need four things from your WordPress installation:
- HTTPS: application passwords only work over an encrypted connection. Practically every website has this today.
- A dedicated user for the blog system, for example "Editorial" or the name of the system. Not the admin account.
- The right role: author is enough if posts should appear as drafts or under their own name. Editor if the system should also edit other people's posts or create categories.
- An application password: in the user profile, under "Application Passwords", enter a name, click "Add New Application Password", and copy the password shown once. It won't be shown again.
There's also a decision to make: which category should the posts fall into? An existing one such as "Guides" or a new one. The category name is stored in the blog system so that no post ends up in "Uncategorised".
What arrives in WordPress with every publication
At BlogPilot, an approved post is handed over in a single pass. The table shows what lands where:
| Element | Where it lands in WordPress |
|---|---|
| Title | Post title |
| Text with subheadings, lists, FAQ section | Content as HTML, displayed by the theme like any other post |
| Internal links to your pages | Within the content, as normal links |
| Excerpt | Post excerpt, shown by many themes in the overview |
| Category | The stored category, several if needed |
| Featured image | Uploaded to the media library first, then set as the featured image |
| Permalink | Derived from the title, following your installation's permalink rules |
| Status | Draft or published, depending on the approval setting |
Everything your theme does with a post happens automatically after that: display in the blog overview, date, author, comment function, sitemap entry. WordPress doesn't know where the post came from, and it doesn't need to.
Why no plugin is needed, and why that's an advantage
Many AI solutions for WordPress come as a plugin. That means: third-party code on your server, updates, dependencies on the theme, possible conflicts with other plugins. Connecting via the REST API needs none of that. Not a single line changes on your website, there's just one extra user. If you ever end the contract, you delete the application password and the posts stay right where they are. What this difference means day to day is covered in the comparison WordPress AI plugins or external blog system.
Security: what you should know
- Limit permissions. The user only gets the role they need. An author can't install plugins, change settings or delete other people's posts.
- Application password instead of login password. The application password only applies to the interface, not to the backend. It can be revoked in the profile with a single click.
- HTTPS only. WordPress does not allow application passwords over unencrypted connections in the first place.
- Check security plugins. Some plugins or hosting firewalls block the REST API for visitors who aren't logged in, or lock out application passwords. In that case, an exception is needed for the editorial user. This is the most common cause when the connection fails on the first test.
- Keep a record. Every post appears under the editorial user, so you can always see in the backend what was created via the interface.
Draft or publish directly
The REST API supports both approaches, and the choice depends on how you work. If you want to see every post before it's published, have it delivered as a draft or approve it by e-mail beforehand. If you trust the process, let it publish directly and keep the option to stop a post at any time. With BlogPilot, approval happens before delivery by e-mail or click, so only what you've seen arrives in WordPress. The post on the approval process in the blog describes the variants with their pros and cons.
What doesn't happen automatically
Honestly, there are limits, and they almost all lie outside the WordPress core:
- Fields from SEO plugins. Meta description and focus keyword in Yoast or Rank Math aren't part of the standard REST API. Whether they get filled in depends on the plugin and its configuration, and this is checked during setup.
- Page builder layouts. Posts arrive as clean HTML. If you want to rebuild every post in Elementor or Divi, you lose the benefit of automation.
- Custom fields. Custom fields from Advanced Custom Fields or similar plugins need to be approved separately.
If it doesn't work on the first test
| Symptom | Likely cause |
|---|---|
| Error 401 or 403 | Application password copied incorrectly, user has insufficient permissions, or a security plugin is blocking it |
| The /wp-json/ address shows an error page | REST API disabled, permalinks set to "Plain", or the host's firewall |
| Post is there, but no image is visible | Theme doesn't display featured images, or upload to the media library was blocked |
| Post in the wrong category | Category name in the blog system doesn't match WordPress |
Most of these issues are resolved within minutes. If your website doesn't run on WordPress, other routes lead to the goal: the connection to Wix, the Shopify blog or a hosted blog. The five-question decision guide shows which option suits which website.
Frequently asked questions
Do I need to install a plugin for the connection to work?
No. The REST API and application passwords are part of the WordPress core. A plugin only comes into play if a security plugin is blocking the REST API and an exception needs to be set up for it.
Does the blog system then have access to my entire website?
No, not if you choose the role correctly. A user with the Author role can create and edit their own posts, but can't change pages, settings or plugins. The application password can be revoked at any time in the user profile without changing the login password.
Does this also work with WordPress.com, or only with self-hosted WordPress?
With self-hosted WordPress, it generally works without restriction. With WordPress.com, whether the REST API is enabled with application passwords depends on the plan you've chosen. This can be tested within minutes before you commit.
What happens to my theme and my design?
Nothing. The posts are treated like manually created posts and are displayed in your theme's design. Subheadings, lists and the FAQ section arrive as normal HTML, which your theme renders like any other post.
Can I edit posts in WordPress afterwards?
Yes. Once delivered, the post belongs to WordPress, you can change, move or delete it in the editor like any other. It's more sensible to make corrections in the blog system before approval, so both sides have the same version.