The WordPress REST API Explained: What It Is and When You Need It

On this page

1. What the REST API is, in plain language
2. What already uses it on your site
3. What's public by default
4. Authentication and application passwords
5. When a business actually needs the REST API
6. Don't switch it off; restrict it

If a developer has mentioned "the REST API", or a security scan has flagged /wp-json/ on your site, you may have wondered what it is and whether to worry. In short: it's a built-in part of WordPress that lets software talk to your website, it's already working on your site, and it needs sensible limits rather than switching off. Here's what business owners and junior developers should know.

What the REST API is, in plain language

Your website normally answers visitors with web pages: HTML designed for people to read. The REST API is a second doorway that answers with plain data instead, in a format called JSON that other programs can read easily. Ask it for your latest blog posts and it returns titles, dates, content and links, without any design.

Each type of data has its own address, called an endpoint, under /wp-json/ on your domain. For example:

https://yoursite.com/wp-json/wp/v2/posts
https://yoursite.com/wp-json/wp/v2/pages
https://yoursite.com/wp-json/wp/v2/categories

Programs can read data from these endpoints and, with permission, create, update or delete it. The REST API has been part of WordPress core since 2016, and plugins can add their own endpoints alongside the built-in ones.

What already uses it on your site

Even if nobody has ever "set up" an API for you, it's probably busy:

• The block editor: when you edit a page in Gutenberg, the editor loads and saves content through the REST API in the background. This is why switching the API off completely can break editing.
• Plugins: many form, SEO, booking and analytics plugins use it to save settings, submit forms or load data without reloading the page.
• WooCommerce: parts of its admin screens and its newer block-based cart and checkout rely on API endpoints, and it has its own API for connecting a store to inventory, accounting or shipping software.
• Apps and integrations: mobile apps, automation tools and CRMs can read or write content through it.
• Headless websites: where a separate front end fetches all its content from WordPress; see headless WordPress for small businesses for whether that's worth it.

What's public by default

Anyone can read the same content through the API that they could already see on your website: published posts and pages, categories, tags and media details. Drafts, private posts and site settings need a logged-in user with the right permissions. Custom post types only appear if they're registered to show in the API, which matters when you structure content such as properties or courses; see custom post types and custom fields.

The user listing

One endpoint surprises people: /wp-json/wp/v2/users. For visitors who aren't logged in, it lists users who have published posts, with each one's display name, profile details and a URL slug. By default that slug is based on the login username, so the list can hand bots the usernames they want for password-guessing attacks.

That isn't a hack in itself (author archive pages often reveal the same slug), but there's no reason to advertise it. Many security plugins can restrict the users endpoint for logged-out visitors. A developer can do the same with a short snippet, while logged-in editors keep full access:

add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        foreach ( array_keys( $endpoints ) as $route ) {
            if ( str_starts_with( $route, '/wp/v2/users' ) ) {
                unset( $endpoints[ $route ] );
            }
        }
    }
    return $endpoints;
} );

Code like this belongs in a small site-specific plugin, not a parent theme, and should be tested on a copy of the site first. Remember that the real protection is strong passwords and two-factor authentication, which make a known username useless to an attacker; see how to secure your WordPress login.

Authentication and application passwords

Reading public content needs no login. Anything that changes or reads private data needs the request to prove who it's from. Common ways:

• Your normal login: when you're logged in to the dashboard, the editor and plugins send requests with your login cookie plus a security token (a nonce), so you never notice
• Application passwords: built into WordPress since version 5.6, for external apps and services
• Plugin-specific keys: WooCommerce, for example, issues its own API keys with read, write or read/write permission, and some plugins add other methods such as tokens

An application password is a long, separate password generated for one app from your profile page under Users. It works only for API requests, not for logging in to the dashboard. It's shown once, and it can be revoked on its own without changing your main password. By default, WordPress only offers application passwords on sites running HTTPS.

Good habits:

• Create one application password per service, with a clear name such as "CRM sync"
• Connect integrations through a dedicated user with the lowest role that works, because the app can do whatever that user can do
• Revoke passwords for services you've stopped using, and any you don't recognise
• Never give an integration, or the person setting it up, your main admin password

When a business actually needs the REST API

Every WordPress site uses it. The real question is whether you need someone to build something with it. A rough guide:

Situation	Custom API work needed?
Brochure site with a contact form and blog	No; it works quietly in the background
Sending website enquiries to a CRM or Google Sheet	Usually not; many form plugins and CRMs have ready-made connections (see connecting forms to a CRM)
Syncing WooCommerce orders or stock with inventory, billing or ERP software	Often, if no reliable ready-made connector exists
A mobile app that shows your products, courses or listings	Yes; the app reads its content from the API
Live calculators, filters or dashboards that update without reloading	Often, through custom endpoints
A headless front end	Yes, for everything

If a developer proposes custom endpoints, ask three questions: who can call each one, what data does it return, and how are permissions checked?

Don't switch it off; restrict it

Some older security advice says to disable the REST API entirely. On a modern site that tends to break the block editor, forms, WooCommerce features and plugin settings. A better approach:

• Restrict specific endpoints that expose more than they should, such as the user listing
• Keep plugins updated: custom endpoints that forget to check permissions are a common source of plugin vulnerabilities
• Deactivate and delete plugins you no longer use, so their endpoints and code are gone
• Use a firewall or security plugin to rate-limit abusive requests to /wp-json/
• Test the editor, forms and checkout after changing any API-related setting

Planning an integration, an app or a headless build, or want your site's API locked down sensibly? I build and maintain integrations as part of WordPress website development, or you can hire me as your WordPress developer for a specific job.