WordPress REST API: A Beginner’s Guide (2026)

ByEditor

TL;DR: The WordPress REST API is a built-in interface that lets any application read and write WordPress data using standard HTTP requests, no PHP required. If you want to build a headless site, a mobile app, or a custom dashboard, the WordPress REST API is your starting point.

Last Updated: April 2026. Tested against WordPress 6.7 running PHP 8.3.

The WordPress REST API is one of the most powerful features in modern WordPress. Introduced in WordPress 4.7 and now fully mature in WordPress 6.7, it gives developers a standardized way to interact with site content from outside the WordPress admin. Whether you are building a mobile app, a decoupled front end, or a custom integration, understanding the WordPress REST API is an essential skill in 2026.

This guide covers everything a beginner needs to know: what the REST API is, the default endpoints available out of the box, how to make GET and POST requests, the authentication methods you need to secure write operations, and practical examples you can run right now.

What Is the WordPress REST API?

More ArticlesHow To Optimize Your Website For First Contentful Paint (FCP)

REST stands for Representational State Transfer. It is an architectural style for networked applications that communicate over HTTP using standard methods like GET, POST, PUT, PATCH, and DELETE. An API (Application Programming Interface) is simply a defined way for two systems to talk to each other.

The WordPress REST API exposes your WordPress site’s data as JSON (JavaScript Object Notation), a lightweight text format that almost every programming language can read. Instead of loading a full WordPress page to retrieve a post title, a client application can send a single HTTP GET request to a URL and receive just the data it needs.

To understand why this matters, it helps to know how WordPress stores content under the hood. WordPress keeps posts, pages, users, and settings in a MySQL database. Traditionally, PHP template files queried that database and rendered HTML. The REST API adds a second path: it queries the same database and returns the raw data as JSON, leaving the rendering to whatever front end you choose. For a deeper look at how WordPress organizes that data, see our guide on WordPress hosting and how your server environment affects API performance.

The official WordPress REST API documentation is maintained at WordPress.org, where you can find the full schema reference for every built-in route.

Why Use the WordPress REST API in 2026?

More ArticlesThe Best Web Hosting For Agencies: Top 5 Options

There are several compelling reasons to work with the WordPress REST API:

  • Headless WordPress: Serve WordPress content to a React, Vue, or Next.js front end while keeping the familiar WordPress admin for content management.
  • Mobile apps: Fetch posts, pages, or custom post types directly into an iOS or Android app without scraping HTML.
  • Third-party integrations: Push data into or pull data from external CRMs, analytics platforms, or marketing tools.
  • Custom admin interfaces: Build internal tools that create or update WordPress content programmatically.
  • Progressive Web Apps: Deliver fast, dynamic experiences by loading only the content that has changed.

For a comparison of the REST API against a newer alternative, see our article on WordPress REST API vs GraphQL for headless builds, which covers the trade-offs in detail.

Default Endpoints Available in WordPress 6.7

Every WordPress site running version 4.7 or later has the REST API enabled by default. The base URL for the API is:

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

Visiting that URL in a browser returns a JSON document describing all available namespaces and routes. The core namespace is wp/v2. Here are the most important default endpoints:

Resource Endpoint Best For
Posts /wp-json/wp/v2/posts Fetching or creating blog posts
Pages /wp-json/wp/v2/pages Fetching or managing static pages
Categories /wp-json/wp/v2/categories Listing or creating categories
Tags /wp-json/wp/v2/tags Listing or creating tags
Media /wp-json/wp/v2/media Uploading images and files
Users /wp-json/wp/v2/users Reading user profiles (authenticated)
Comments /wp-json/wp/v2/comments Fetching or submitting comments
Custom Post Types /wp-json/wp/v2/{cpt-slug} Any registered custom post type
More ArticlesIs WordPress Good for E-Commerce?

Each endpoint supports standard HTTP verbs. GET requests return data, POST requests create new resources, PUT and PATCH requests update existing resources, and DELETE requests remove them. Most write operations require authentication, which is covered below.

How to Make a GET Request to the WordPress REST API

GET requests are the simplest way to start working with the WordPress REST API. They are unauthenticated by default, meaning you can fetch published content without any credentials. This is intentional because published posts are already public.

Fetching Posts with a Browser or curl

The simplest request you can make is to retrieve the 10 most recent published posts:

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

You can paste that URL directly into a browser or run it via curl in your terminal:

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

The response is a JSON array. Each object in the array represents one post and includes fields like id, date, slug, title, content, excerpt, author, and featured_media.

Common Query Parameters

The WordPress REST API supports a rich set of query parameters that let you filter and page through results:

# Return 5 posts per page, starting from page 2
GET /wp-json/wp/v2/posts?per_page=5&page=2

# Filter by category ID 12
GET /wp-json/wp/v2/posts?categories=12

# Search for posts containing a keyword
GET /wp-json/wp/v2/posts?search=headless+wordpress

# Return only specific fields to reduce payload size
GET /wp-json/wp/v2/posts?_fields=id,title,slug,date

Using _fields is a good practice in production. Instead of returning the full post object, including the rendered HTML content, you receive only the fields you actually need. This reduces bandwidth and speeds up your application.

Fetching a Single Post by ID

To retrieve a specific post by its WordPress post ID, append the ID to the endpoint:

GET /wp-json/wp/v2/posts/42

This returns a single JSON object for post ID 42. You can also fetch a post by slug using the slug parameter:

GET /wp-json/wp/v2/posts?slug=my-post-slug

Understanding how WordPress assigns these IDs and slugs connects directly to how the database is structured. Our article on how WordPress stores data explains the underlying table structure that the REST API queries.

How to Make a POST Request: Creating Content

Write operations through the WordPress REST API require authentication. Attempting a POST request without credentials will return a 401 Unauthorized or 403 Forbidden error. Once you have a valid authentication method set up (covered in the next section), creating a post looks like this using curl:

curl -X POST https://yoursite.com/wp-json/wp/v2/posts 
  -H "Content-Type: application/json" 
  -u "your_username:your_application_password" 
  -d '{
    "title": "My New Post via REST API",
    "content": "This post was created programmatically.",
    "status": "publish"
  }'

A successful POST request returns the full JSON object for the newly created post, including its new id, slug, and link. The status field can be set to publish, draft, pending, or private.

Updating a Post with PUT or PATCH

To update an existing post, use PUT (replace the entire resource) or PATCH (update only specific fields). PATCH is more efficient for small updates:

curl -X PATCH https://yoursite.com/wp-json/wp/v2/posts/42 
  -H "Content-Type: application/json" 
  -u "your_username:your_application_password" 
  -d '{"title": "Updated Post Title"}'

WordPress REST API Authentication Methods

Choosing the right authentication method depends on your use case. Here is a comparison of the three most common options available in WordPress 6.7:

Method Setup Required Best For Security Level
Application Passwords Built-in (WP 5.6+) Server-to-server integrations, scripts High (HTTPS required)
Cookie Authentication Built-in (uses nonce) JavaScript running inside the WP admin Medium (same-origin only)
JWT Authentication Plugin required External apps, mobile clients, SPAs High (token-based)

Application Passwords (Recommended for Most Use Cases)

Application Passwords were added to WordPress core in version 5.6 and are the simplest way to authenticate REST API requests from external scripts or services. To create one:

  1. Go to Users in your WordPress admin and click on your user profile.
  2. Scroll down to the Application Passwords section.
  3. Enter a name for the application (for example, “My API Script”) and click Add New Application Password.
  4. Copy the generated password immediately. WordPress will not display it again.

Use the application password with HTTP Basic Authentication, sending your WordPress username and the application password as credentials. The password contains spaces in the displayed format but works with or without them in the Authorization header. Always send requests over HTTPS when using Application Passwords, as the credentials are transmitted in Base64 encoding, which is not encrypted on its own.

Cookie Authentication with Nonces

If you are writing JavaScript that runs inside the WordPress admin (for example, a Gutenberg block or a custom admin page), WordPress automatically provides a nonce for authenticating REST API requests. You do not need to set up anything extra. WordPress exposes the nonce through wp_localize_script() or the global wpApiSettings object, and you pass it as an X-WP-Nonce header:

fetch('/wp-json/wp/v2/posts', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-WP-Nonce': wpApiSettings.nonce
  },
  body: JSON.stringify({
    title: 'New Post from Admin JS',
    status: 'draft'
  })
});

Cookie authentication only works for requests originating from the same domain. It is not suitable for external applications.

JWT Authentication

JSON Web Tokens (JWT) are stateless tokens that are well suited for mobile apps and single-page applications. JWT authentication is not built into WordPress core and requires a plugin such as JWT Authentication for WP REST API (available on WordPress.org). The flow involves a client sending credentials to a token endpoint, receiving a signed JWT, and then including that token as a Bearer token in subsequent requests:

# Step 1: Obtain a token
POST /wp-json/jwt-auth/v1/token
Body: { "username": "admin", "password": "yourpassword" }

# Step 2: Use the token in subsequent requests
GET /wp-json/wp/v2/posts
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Tokens have an expiry time, which adds a layer of security compared to static application passwords. If a token is compromised, it becomes invalid once it expires.

Practical Example: Fetching Posts with JavaScript in 2026

Here is a complete, working example that fetches the five most recent WordPress posts and renders their titles in an HTML page. This uses the Fetch API, which is supported natively in all modern browsers and Node.js 18+.

async function getLatestPosts(siteUrl, count = 5) {
  const endpoint = `${siteUrl}/wp-json/wp/v2/posts?per_page=${count}&_fields=id,title,slug,date,excerpt`;

  try {
    const response = await fetch(endpoint);

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const posts = await response.json();

    posts.forEach(post => {
      console.log(`[${post.id}] ${post.title.rendered}`);
      console.log(`  Slug: ${post.slug}`);
      console.log(`  Published: ${new Date(post.date).toLocaleDateString()}`);
    });

    return posts;
  } catch (error) {
    console.error('Failed to fetch posts:', error);
  }
}

// Usage
getLatestPosts('https://yoursite.com');

Notice the use of _fields to limit the response to only the fields we need. The title.rendered property contains the post title with any HTML entities decoded, which is typically what you want to display. The raw title.raw property is only available to authenticated users with edit permissions.

Extending the WordPress REST API with Custom Endpoints

The built-in endpoints cover posts, pages, and taxonomies, but most real applications need more. The WordPress REST API is designed to be extended. You can register custom routes using the register_rest_route() function inside a plugin or your theme’s functions.php file.

Here is a minimal example that creates a custom endpoint at /wp-json/myplugin/v1/stats:

add_action( 'rest_api_init', function () {
    register_rest_route( 'myplugin/v1', '/stats', array(
        'methods'             => 'GET',
        'callback'            => 'myplugin_get_stats',
        'permission_callback' => '__return_true', // Public endpoint
    ) );
} );

function myplugin_get_stats( WP_REST_Request $request ) {
    $post_count = wp_count_posts( 'post' )->publish;
    return rest_ensure_response( array(
        'published_posts' => (int) $post_count,
        'site_name'       => get_bloginfo( 'name' ),
    ) );
}

Setting permission_callback to '__return_true' makes the endpoint public. For protected endpoints, return a WP_Error or a boolean based on current_user_can(). Never use '__return_true' on an endpoint that exposes or modifies sensitive data.

Custom endpoints are also useful when you have custom post types registered with show_in_rest set to true. When you register a custom post type and include 'show_in_rest' => true, WordPress automatically creates REST API endpoints for that post type under its slug. You can read more about building custom post types in our guide on headless WordPress approaches.

Performance and Security Considerations

Before you deploy an application that relies on the WordPress REST API, keep these points in mind:

  • Rate limiting: WordPress does not include built-in rate limiting for the REST API. If your endpoints are publicly accessible, consider adding server-level rate limiting at the NGINX or Apache layer, or using a security plugin that supports REST API throttling.
  • Caching: GET requests to the REST API can be cached at the server or CDN level. A good managed WordPress host handles this automatically. GigaPress managed WordPress hosting, starting at $2.40/month with a 99.9% uptime SLA, includes server-side caching that benefits REST API consumers as well as traditional page loads.
  • Disabling the API for unauthenticated users: If your site has no reason to expose content to external applications, you can restrict the REST API to authenticated users by hooking into the rest_authentication_errors filter. Be careful not to break Gutenberg, which relies on the REST API internally.
  • HTTPS is mandatory: Any REST API endpoint that accepts or returns sensitive data, including Application Password credentials, must run over HTTPS. Most modern WordPress hosts provide free SSL certificates.
  • Pagination headers: The REST API returns the total number of posts and the total number of pages in the response headers X-WP-Total and X-WP-TotalPages. Read these headers to build proper pagination in your application.

How WordPress Stores Data Behind the REST API

To debug REST API responses effectively, it helps to understand what the API is actually reading. Every post returned by /wp-json/wp/v2/posts corresponds to a row in the wp_posts database table. Post meta fields, such as custom fields added by plugins, are stored in wp_postmeta and are only included in REST API responses if they have been explicitly registered with register_meta() and the show_in_rest argument set to true.

Understanding this relationship helps you know why some fields appear in API responses and others do not. The full picture of how WordPress organizes posts, pages, and custom data is explained in our guide on WordPress REST API vs GraphQL, which also covers how different data-fetching strategies compare for complex sites. For a thorough look at the database itself, refer to our article on where WordPress posts and pages are stored, which covers the exact table structure that the REST API queries.

Ready to Upgrade Your Website?

If you’re looking for fast WordPress hosting and done-for-you updates, check out our hosting packages by clicking the button below. A high-performance managed WordPress host ensures your REST API endpoints respond quickly, handles HTTPS automatically, and provides the server resources headless and API-driven builds demand.

Frequently Asked Questions About the WordPress REST API

Is the WordPress REST API enabled by default?

Yes. The WordPress REST API has been enabled by default since WordPress 4.7, released in December 2016. Every WordPress site running a modern version has the API available at /wp-json/wp/v2/ with no configuration required. Gutenberg, the block editor introduced in WordPress 5.0, relies on the REST API internally for all its read and write operations.

Do I need a plugin to use the WordPress REST API?

No plugin is required for basic usage. The core REST API, including endpoints for posts, pages, categories, tags, media, and users, is built into WordPress. Plugins can extend the API with additional endpoints or add custom fields to existing responses, but you can start making GET requests immediately after installing WordPress with no additional plugins.

What is the difference between the WordPress REST API and GraphQL?

The REST API uses fixed endpoints, with one URL per resource type. GraphQL uses a single endpoint and lets the client specify exactly which fields to return in a query. REST is simpler to learn and has broad native support in WordPress. GraphQL requires the WPGraphQL plugin and offers more flexibility for complex, nested data requirements. For most beginner projects, the REST API is the right starting point.

Can I disable the WordPress REST API for security reasons?

You can restrict unauthenticated access to the REST API using the rest_authentication_errors filter, but completely disabling it will break the Gutenberg block editor and many plugins that depend on it internally. A safer approach is to restrict specific sensitive endpoints (such as the users endpoint) rather than disabling the entire API. If you need to hide the API from non-logged-in visitors, use the filter to return a WP_Error for unauthenticated requests.

How do I add custom fields to the WordPress REST API response?

Custom fields (post meta) are not included in REST API responses by default. To expose a custom field, register it with register_post_meta() and set the show_in_rest argument to true. Alternatively, use register_rest_field() for more control over how the field is retrieved and updated. Both approaches are available without any additional plugins and work in WordPress 6.7 with PHP 8.3.

Similar Posts