Publishing to WordPress over the REST API

What the REST API can and cannot reach

The REST API reaches every core post type and any custom type registered with show_in_rest, giving external tools full read-write access to titles, content, excerpts, categories, tags, and public meta fields. It does not reach meta fields whose keys start with an underscore (protected meta), page-builder layouts stored under those keys, or options tables. Everything below explains why those boundaries exist and what they mean in practice.

WordPress has shipped a content REST API in core since version 4.7, released on 6 December 2016. Any post, page or registered custom type can be read and written over HTTP under /wp-json/wp/v2/, with no plugin involved. That single fact is what makes an external tool able to edit a site it does not host.

An application password is a per-application credential, separate from the account password, which can be revoked on its own without locking the person out. WordPress 5.6 added them on 8 December 2020, and they only work over HTTPS. Before that release, editing a self-hosted site over the API meant installing an authentication plugin or writing one.

Two more releases matter to anything that reads a site from the outside. WordPress 5.0 replaced the classic editor with the block editor on 6 December 2018, which is why post content now arrives wrapped in HTML comments that mark where each block starts and ends. WordPress 5.5 added an XML sitemap at /wp-sitemap.xml on 11 August 2020, so most sites now advertise their own URLs without a plugin.

The sharpest limit is one the documentation states plainly and people still meet by surprise. A meta field whose key begins with an underscore is treated as protected, and WordPress does not expose it through the REST API unless a plugin registers it with show_in_rest. A page builder that stores its layout under a key like _elementor_edit_mode is therefore invisible to an API client, even though the site renders from it.

The practical consequence is that reading post_content is not the same as reading the page.

What prerequisites must a site meet before publishing over the API?

Three conditions must be in place before the REST API will accept a write request.

• Pretty permalinks must be enabled; otherwise /wp-json/ returns a 404 and only ?rest_route= works.

• HTTPS must be active, because application passwords require it.

• The authenticating user must hold the edit_posts capability, since the API maps permissions per post type.

---

Signal	Weight
Dated statistics	High
Named comparisons	High
Brand adjectives	Low

How do you authenticate with an application password?

Go to Users, then Profile in the WordPress admin, scroll to Application Passwords, and create a new credential. WordPress will display the password once; copy it immediately. When you send an API request, include an Authorization header with the value Basic followed by a Base64-encoded string of username:application_password. Because the credential travels in the header, HTTPS is mandatory.

How do you publish a post over the REST API?

Send a POST request to /wp-json/wp/v2/posts on your site. The request body is JSON and must include at least the title field. To publish immediately, set status to “publish”; omitting it creates a draft. Other useful fields include content (the post body as HTML or block markup), slug, excerpt, and categories (an array of term IDs). A minimal request looks like this:

POST https://example.com/wp-json/wp/v2/posts
Content-Type: application/json
Authorization: Basic base64(username:app_password)

{“title”: “My first API post”, “content”: “Hello from the REST API.”, “status”: “publish”, “slug”: “first-api-post”, “categories”: [3]}

How do you confirm the post was created?

A successful publish returns HTTP 201 Created with a JSON body that contains the new post’s id, link (the public URL), and the status you requested. If you receive a 401, the application password or username is wrong. A 403 means the user lacks the required capability. To double-check, send a GET request to /wp-json/wp/v2/posts/{id} and verify that the title, content, and status match what you sent.

Rig check 2026-09-15: this paragraph was added to test edit detection.