WordPress REST API: Using WordPress as a Backend

Most people think of WordPress as nothing more than a blogging and website platform, yet hidden inside it is a remarkably powerful tool — the REST API. This interface exposes everything WordPress stores (posts, pages, users, taxonomies, comments) in standard JSON format to external applications. As a result, WordPress stops being merely a system that renders pages and becomes a full-fledged content backend, meaning you can build the frontend in any technology you like and treat WordPress purely as a data source.

In modern web development this idea is called "headless WordPress." With this approach the WordPress admin panel remains for managing content, while the user-facing interface is built separately as a React, Vue, Next.js application or a mobile client. This separation makes a site faster, more secure and more flexible, because the frontend and backend evolve independently of one another. If you are a developer, the REST API lets you build modern interfaces while keeping all the conveniences of the WordPress ecosystem.

How the REST API works and its core endpoints

The WordPress REST API accepts every request under the /wp-json/ path. The core endpoints live in a versioned namespace called wp/v2, which ensures that existing integrations keep working even if the API changes in the future. The most commonly used routes are those that return posts, pages, users and categories, and each of them is controlled through standard HTTP methods.

GET  /wp-json/wp/v2/posts          # list of all posts
GET  /wp-json/wp/v2/posts/42       # post with ID 42
GET  /wp-json/wp/v2/pages          # pages
GET  /wp-json/wp/v2/users          # users
GET  /wp-json/wp/v2/categories     # categories

# Filtering and pagination parameters
GET  /wp-json/wp/v2/posts?per_page=5&page=2&search=domain&orderby=date

Each response comes back as a JSON array or object containing the post title, content, date, author and other metadata. You can simply open an address like https://yoursite.uz/wp-json/wp/v2/posts in a browser to see this data immediately — no plugin needs to be installed, because the REST API is baked into the WordPress core.

Reading data: GET requests

Read operations usually work without authentication, since published posts are open to any visitor. Fetching data in a modern frontend with JavaScript looks like the following. This example grabs the latest five posts and prints their titles to the console, and this very approach forms the foundation of a React or Vue application.

async function getPosts() {
  const response = await fetch(
    'https://example.uz/wp-json/wp/v2/posts?per_page=5&_embed'
  );
  const posts = await response.json();

  posts.forEach(post => {
    console.log(post.title.rendered);
    console.log(post.excerpt.rendered);
  });
}

getPosts();

The _embed parameter is especially valuable because it adds related objects to the response, such as author data and the featured image. Without it you would have to send a separate request for each image or author, which would slow the application down. This way a single optimised request gives you all the data needed to render a post in full.

Authentication: application passwords and JWT

Writing, editing or deleting data, however, always requires authentication, otherwise anyone could change your site's content. Starting with WordPress 5.6 the core ships with an Application Passwords mechanism that lets you create a separate secret key for the API without exposing your main password. This key is generated from the user profile and can be revoked at any time.

# Creating a post with an application password (HTTP Basic Auth)
curl -X POST https://example.uz/wp-json/wp/v2/posts \
  -u "admin:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "A post created through the API",
    "content": "This content was sent programmatically.",
    "status": "publish"
  }'

In more complex projects, particularly mobile apps, the JWT (JSON Web Token) method is more convenient. Here the user obtains a token once using a login and password, and then passes that token in every request through the Authorization: Bearer header. The JWT approach is installed via a dedicated plugin and is stateless, meaning it requires no session storage on the server side, so it scales well in high-traffic applications.

Building a custom endpoint

The standard endpoints may not cover every need — for example, you might want a response that joins data from several tables or requires special logic. In that case you create your own route using WordPress's register_rest_route function. The following code is added to a theme file or a plugin and creates a new address /wp-json/myapp/v1/featured.

add_action('rest_api_init', function () {
  register_rest_route('myapp/v1', '/featured', [
    'methods'  => 'GET',
    'callback' => 'myapp_get_featured',
    'permission_callback' => '__return_true',
  ]);
});

function myapp_get_featured($request) {
  $count = $request->get_param('count') ?: 3;

  $query = new WP_Query([
    'posts_per_page' => intval($count),
    'meta_key'       => 'is_featured',
    'meta_value'     => '1',
  ]);

  $result = [];
  foreach ($query->posts as $post) {
    $result[] = [
      'id'    => $post->ID,
      'title' => get_the_title($post),
      'link'  => get_permalink($post),
    ];
  }

  return new WP_REST_Response($result, 200);
}

Here permission_callback is a crucial element that determines who may access the endpoint. For open data you use __return_true, but for protected information you must write logic inside it that checks the user's permissions. Otherwise your custom endpoint could turn into a security hole.

Security and best practices

Because the REST API opens your site to the outside world, security demands particular attention. The first and foremost rule is that all requests must travel over HTTPS, since an application password or JWT token sent over plain HTTP can be intercepted easily. In addition, in your write and delete endpoints always verify the user's role and permissions, allowing only the operations that are explicitly permitted.

Another important aspect is rate limiting, which prevents automated attacks and excessive load on the server. If your site does not need the REST API or uses only certain endpoints, disabling the rest reduces the attack surface. The /users endpoint, which reveals the list of users, is also frequently restricted because it exposes login names and makes brute-force attacks easier.

When and how to use it

The WordPress REST API becomes an especially strong solution in situations like these: when the same content needs to be distributed simultaneously to a website, a mobile app and other platforms; when you want to build a fast React or Vue interface and use WordPress only as a content store; or when you need to integrate WordPress data with a CRM, a shop system or analytics tools. In each of these cases the API preserves WordPress's editing convenience while giving you full control over the frontend.

If you currently run an ordinary WordPress site and want to turn it into a modern application in the future, learning the REST API is an excellent investment. The best approach is to create a small custom endpoint, try fetching data from it, and gradually move towards a headless architecture. That way your site will be ready not only for today's needs but for tomorrow's as well.