Table of contents
What is an API?What is the REST API?What is the WordPress REST API?How does it work?How to access the WordPress REST APIAuthentication & securityWordPress REST API commandsWordPress REST API examplesWhen not to useHow to disableNext stepsAdditional resources
Get the industry’s fastest hosting for WordPress◦ 100% network uptime
◦ Comprehensive security
◦ 24/7 support
Explore options

WordPress Guide → Admin → REST API

What is WordPress REST API and how do you use it?

If you’ve spent any time in the WordPress world, you’ve probably heard about the WordPress REST API – and for good reason. It’s what allows your WordPress site to communicate with apps, front-end frameworks, or even other websites, opening the door to custom dashboards, mobile apps, and headless setups.

Think of it as giving WordPress a way to talk – clearly and efficiently – with the outside world. And while it sounds technical, it’s surprisingly approachable once you get the basics.

In this guide, we’ll break down exactly what the WordPress REST API is, how it works, when to use it, and how to power it up.

Get fast, reliable hosting for WordPress

Power your site with the industry’s fastest, most optimized WordPress hosting

WordPress.org hosting

What is an API?

Before we can truly understand the WordPress REST API, we need to take a step back and look at what an API actually is.

API stands for Application Programming Interface. It’s a way for two different programs or systems to talk to each other. Think of it like a waiter at a restaurant: you (the user) tell the waiter what you want, and the waiter brings that request to the kitchen (the system), then delivers the result back to you. You don’t need to know how the food is made – you just make a request, and the API handles the back-and-forth.

In technical terms, an API defines a set of rules and protocols for how software components should interact. It says, “Here’s how you ask me for data, and here’s what I’ll give you in return”. These interactions can include getting data, sending data, updating something, or even deleting it.

What is the REST API?

Now that we’ve covered what an API is, let’s talk about a specific type: the REST API.

REST stands for Representational State Transfer – a set of architectural rules that make it easier for systems to communicate over the web using standard HTTP methods like GET, POST, PUT, and DELETE.

A REST API follows these rules to structure requests and responses in a predictable way. The goal is to make it easy for clients (like a web browser, mobile app, or script) to request and interact with resources on a server (like posts, users, products, or comments).

Here’s an example: If you want a list of blog posts, you might send a GET request to example.com/api/posts, and the server would return that data in a format like JSON. If you want to update a post, you’d send a PUT request with the new info.

What makes REST APIs so popular is their simplicity, scalability, and flexibility. They’re language-agnostic, which means a JavaScript front end, a Python script, or a mobile app can all talk to the same REST API without issue as long as they follow the rules.

What is the WordPress REST API?

In the context of WordPress, the REST API is a built-in feature that allows developers to access and interact with WordPress site data using HTTP requests. It turns your WordPress site into a data hub that can be read from or written to – all using JSON, a lightweight data format that’s easy for both humans and machines to work with.

Instead of rendering full pages through PHP templates, the REST API makes it possible to get just the data you need – whether that’s posts, pages, users, media, or even custom content types. This opens the door to building completely custom front ends, single-page applications, mobile apps, and more.

The WordPress REST API has completely changed how developers approach WordPress – taking it from a monolithic CMS to a flexible application framework. Here are some powerful use cases where the REST API shines:

  • Headless WordPress: Use WordPress as your content engine (the “back end”) while building your front end with JavaScript frameworks like React, Vue, or Next.js.
  • Mobile apps: Power iOS or Android apps with WordPress content by pulling in posts, user data, or eCommerce info via the API.
  • Custom dashboards: Build admin interfaces that are faster, cleaner, and more intuitive without relying on the default WordPress admin area.
  • Third-party integrations: Connect your WordPress site to CRMs, marketing platforms, inventory systems, or analytics tools, all via standardized API endpoints.
  • Real-time content updates: Combine the REST API with JavaScript to create dynamic, real-time updates on the front end – think live search, comments, or notifications.

As you can probably tell, this gives developers way more creative and architectural freedom than ever before.

WordPress REST API concepts and how they work

Routes and endpoints

In REST API terms, a route is the URL path you use to access a particular resource. An endpoint is a specific function or action tied to that route.

Think of a route like a street address (/wp-json/wp/v2/posts), and an endpoint as what happens when you ring the doorbell (fetch posts, update a post, delete one, etc.).

Example:

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

This route gives you access to all your published blog posts.

If you want a specific post? Use:

https://yoursite.com/wp-json/wp/v2/posts/42

And if you want to see all comments for a post? Try:

/wp-json/wp/v2/comments?post=42

The structure is intuitive: /wp-json/ is the base URL for the API, followed by versioning (v2) and the resource you want to access (posts, pages, users, etc.).

Request and responses

When you interact with the REST API, you’re sending a request to the server and getting a response back, usually in JSON.

Requests come in different flavors:

  • GET – to read data.
  • POST – to create new data.
  • PUT or PATCH – to update existing data.
  • DELETE – to remove data.

Example request:

GET /wp-json/wp/v2/posts

The response will be a JSON array of posts, with fields like title, date, slug, and content.

Each response also includes headers and status codes (like 200 OK or 401 Unauthorized) to tell you how the request went.

Schemas

A schema is a blueprint that describes what a particular piece of data looks like – what fields exist, what types they are (string, number, boolean), and whether they’re required or optional. It helps developers know what to expect and what’s allowed when creating or updating resources.

You can inspect a schema by making an OPTIONS request to any endpoint.

Example:

OPTIONS /wp-json/wp/v2/posts

This returns a JSON object showing all the fields you can send or receive when working with posts.

Controllers

Controllers are behind-the-scenes handlers that define how each route behaves. They determine what happens when a request hits a specific endpoint – which data to fetch, how to process it, what permissions are required, and how to return the result.

Most of the time, you won’t need to write custom controllers unless you’re building your own custom routes or extending the REST API. But knowing they exist helps you understand the power under the hood – and gives you options for more advanced customizations.

These concepts work together to make the WordPress REST API both powerful and approachable. You define a route, send a request, receive a response (structured by a schema), and the controller does the heavy lifting in the background.

How to access the WordPress REST API

Here are the most common ways to access and interact with the WordPress REST API:

Direct HTTP requests via a browser

You can access these endpoints directly using your browser or any HTTP client like cURL or Postman. The base URL for the WordPress REST API is typically:

https://yourdomain.com/wp-json/wp/v2/

Replace yourdomain.com with the actual domain of your WordPress site.

You can query specific endpoints by appending them to the base URL. For example:

  • To get a list of posts:
https://yourdomain.com/wp-json/wp/v2/posts
  • To access a specific post by ID (this will return the data of the post with ID 1 in JSON format): 
https://yourdomain.com/wp-json/wp/v2/posts/1

Also, keep in mind that many WordPress REST API endpoints, especially those that involve creating, updating, or deleting data, require authentication (which we’ll get into later).

Using WP-CLI

WP-CLI, WordPress’s command-line interface, offers a streamlined way to interact with the REST API through its restful package. 

To access the REST API with WP-CLI, you’ll need to use commands like wp rest request or wp rest get. Here’s how you can use WP-CLI to send a GET request to retrieve posts:

wp rest request --path=your-wordpress-installation-path --url=https://yourdomain.com/wp-json/wp/v2/posts

This will retrieve the list of posts in JSON format.

You can also send a POST request to create new content via the REST API with WP-CLI:

wp rest request --path=your-wordpress-installation-path --url=https://yourdomain.com/wp-json/wp/v2/posts \
  --method=POST \
  --data='{"title":"New Post Title", "content":"Content of the new post.", "status":"publish"}'

This will create a new post with the provided title and content.

Authentication and security

By default, public endpoints like retrieving posts or pages don’t require authentication. Anyone – including your browser, an app, or a random script – can access them. But if you want to create, update, or delete content or access user data, you’ll need to authenticate the request.

There are a few ways to do this securely, depending on the use case:

Cookie authentication (for logged-in users)

If you’re logged into WordPress (like when you’re working in the admin dashboard), WordPress uses a special authentication cookie behind the scenes. This is mostly useful for JavaScript running within the WordPress site, such as in custom Gutenberg blocks or admin interfaces.

It’s easy, it’s secure, but it only works for users already logged into your WordPress site.

Application passwords (easy and built-in)

Introduced in WordPress 5.6, application passwords offer a simple way to authenticate external applications. You generate a unique password tied to your user account, then use it in API requests. It’s basic authentication – just over HTTPS – and great for use cases like integrating with third-party tools or testing API requests from tools like Postman.

OAuth (for advanced, third-party integrations)

OAuth 1.0a is a more secure, more complex method of authentication. It allows third-party apps to access WordPress on a user’s behalf without exposing their login credentials.

This is ideal for mobile apps, SaaS platforms, or any situation where the user is granting limited access to their account. It requires setting up keys, secrets, and handling token exchanges – but it’s the industry standard for secure, scalable integrations.

You’ll typically use a plugin like WP OAuth Server or build a custom OAuth handler if you’re going this route.

Security best practices

No matter which method you use, here are a few key tips to keep your API secure:

  • Use HTTPS for all API requests – always. No exceptions.
  • Limit permissions by using custom roles or capabilities when registering endpoints.
  • Rate-limit requests to prevent abuse or brute force attacks.
  • Sanitize and validate all incoming data, even if it looks safe.
  • Log activity if your API is exposed to third parties or critical business functions.

And yes, the WordPress REST API is secure as long as you implement proper authentication, use HTTPS, and follow security best practices.

WordPress REST API commands

GET commands

The GET method is the most commonly used. It retrieves data from your WordPress site and it’s read-only, meaning they don’t modify anything – they just return data. With it, you can:

  • List all posts, pages, users, media, categories, tags, and more.
  • Filter by parameters like author, category, or post status.
  • View custom post types and taxonomies if they’re registered with REST support.

POST commands

POST is used to create new content. You’ll need to be authenticated to use this command, and your user must have permission to create posts (typically an Author or above).

Other uses for this command include submitting comments, uploading media, and creating custom data entries via custom endpoints.

PUT (or PATCH) commands

PUT is used to update existing data. PATCH is similar to PUT, but it’s usually used for partial updates (i.e. changing just one field). Both can be used depending on the API design.

You must be authenticated and have permission to edit the specific resource you’re updating.

DELETE commands

The DELETE method does exactly what it sounds like – it removes a resource. By default, this will move the post to the trash. To permanently delete it, you can include a query parameter:

DELETE /wp-json/wp/v2/posts/42?force=true

Be careful – this is permanent, and there’s no “Are you sure?” prompt!

WordPress REST API examples

Example 1: GiveWP blog posts

Take a look at the GiveWP website. If you head over to their blog, you’ll see a familiar WordPress layout with recent posts. All standard stuff, right?

Now try this:

https://givewp.com/wp-json/wp/v2/posts

What you’re seeing is the same content – but in raw JSON format, designed for developers to consume programmatically.

Let’s break it down:

  • /wp-json/ tells WordPress to serve data from its REST API.
  • wp/v2/ is the version of the API.
  • posts is the specific resource you’re accessing.

Instead of loading the entire blog page (with HTML, CSS, and all the styling), a developer or app can just pull the post data directly and use it wherever they want. This is perfect for building custom front ends, mobile views, or content aggregators.

And here’s something even cooler: when the Latest Posts block is used in Full Site Editing, WordPress uses this exact route behind the scenes. Rather than reloading the whole page, it calls the REST API to fetch fresh post data and updates the block only, keeping everything snappy and smooth.

Example 2: Gutenberg + REST API

When you use the WordPress block editor (aka Gutenberg), you’re interacting with the REST API all the time even if you don’t realize it. For instance, when you insert a “Latest Posts” block or search for media in the editor, Gutenberg sends GET requests to REST endpoints like:

/wp-json/wp/v2/posts

/wp-json/wp/v2/media

And when you click “Publish” on a post, it’s a POST request to the API.

Behind the scenes, Gutenberg is essentially a JavaScript application that speaks REST. That means developers can build custom blocks or entire editing experiences that interact with WordPress data without ever touching PHP templates.

When not to use the WordPress REST API

Compatibility limitations

If your WordPress site relies heavily on legacy plugins or themes that aren’t built with REST API compatibility in mind, you could run into issues. Many plugins do not expose their data via custom REST endpoints, which means you may need to build those endpoints yourself.

Also, if you’re using advanced features like shortcodes or complex custom fields (especially with older implementations), they may not be easily accessible through the API without extra work.

Accessibility considerations

While the REST API allows for slick, dynamic front ends (especially in headless setups), those custom interfaces can unintentionally leave accessibility behind.

WordPress core, by design, does a lot to ensure accessibility out of the box. When you bypass the native theming system and build everything from scratch, you’re now responsible for ensuring keyboard navigation, screen reader compatibility, semantic HTML, and more.

So, if your project has strict accessibility requirements and your team lacks deep accessibility expertise, sticking with traditional WordPress theming might be the safer choice.

SEO implications

This one’s big: REST API-powered front ends don’t always play nicely with SEO unless you build for it intentionally.

When you go headless or serve content purely through JavaScript, search engines might have a harder time indexing your content unless you implement Server-Side Rendering (SSR) or Static Site Generation (SSG).

Without those, your site may render blank pages to bots, and you could lose out on organic traffic. So, if you rely heavily on search engine traffic and aren’t prepared to implement SSR or SEO-friendly techniques, using the REST API for core content delivery could hurt more than help.

How to disable the WordPress REST API

Option 1: Disable REST API for all users

If you want to completely disable the WordPress REST API for all users – whether they are logged in or not – you can use a simple filter in your child theme’s functions.php file or within a custom plugin:

add_filter('rest_enabled', '__return_false');

This will effectively block all incoming requests to the REST API. However, be cautious with this method, as it will prevent even authenticated users (including administrators) from interacting with the API. This means some functionality, such as Gutenberg blocks or certain plugins that rely on the REST API, may no longer work properly.

Option 2: Disable REST API for logged-out users

In some cases, you might only want to disable the REST API for users who are not logged in. This approach allows authenticated users (like admins or editors) to continue using the API, but blocks public access for security purposes.

To do this, you can use the following code in your functions.php file:

add_filter('rest_authentication_errors', function($result) {
    if (!is_user_logged_in()) {
        return new WP_Error('rest_forbidden', __('You cannot access the REST API without logging in.'), array('status' => 401));
    }
    return $result;
});

This code checks whether the user is logged in before allowing access to the REST API. If the user is not logged in, they’ll receive a “403 Forbidden” error when attempting to access any API endpoints.

Option 3: Disable REST API for specific endpoints

If you only want to disable certain API endpoints rather than the entire API, you can do so by hooking into the rest_api_init action:

add_action('rest_api_init', function() {
    remove_action('rest_api_init', 'wp_oembed_register_route');
    remove_action('rest_api_init', 'wp_rest_posts_controller');
}, 15);

This will prevent access to the posts endpoint, but other API endpoints will remain functional. You can apply similar methods for other endpoints, depending on what you need to block.

Option 4: Use a plugin to disable the REST API

If you prefer not to dive into code or need a simpler way to disable the REST API, there are several plugins available that can handle this for you. Some popular options include:

  • Disable WP REST API – a lightweight plugin that allows you to completely disable the REST API.
  • WP Disable REST API – another easy-to-use plugin that blocks REST API access based on your preferences.

These plugins typically offer a straightforward interface where you can toggle whether the API should be disabled for all users or just unauthenticated visitors.

Additional resources

How to use your WordPress admin login page →

How to find, use, and troubleshoot your admin page

What is WordPress version control? →

Learn why it’s important and explore your options.

How to create a sitemap in WordPress →

Three strategies that will help you get set up quickly