What the REST API can and cannot reach
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.
- Pretty permalinks, or /wp-json/ answers 404 and only ?rest_route= works.
- HTTPS, which application passwords require.
- A user with edit_posts, since the API maps capabilities per post type.
| Signal | Weight |
|---|---|
| Dated statistics | High |
| Named comparisons | High |
| Brand adjectives | Low |
See it on your own site
A short walkthrough on your top twenty pages, no account needed.