WordPress REST API: Endpoints & Authentication (2026)
Table of Contents
Every time you use the WordPress block editor, it is talking to a REST API behind the scenes. Every time a mobile app pulls your latest blog posts, it is hitting a REST API. Since WordPress 4.7, the REST API has been a core part of WordPress — and in 2026, it is the foundation that AI agents like Claude use to read and write your site through MCP.
This guide explains what the WordPress REST API is, how its endpoints and authentication work, what headless WordPress means in practice, where the REST API falls short, and how the Model Context Protocol sits on top of it to give AI assistants reliable, typed access to your site.
What Is the WordPress REST API?
The WordPress REST API is a built-in interface that lets any application — a mobile app, a JavaScript frontend, a third-party service, or an AI agent — interact with your WordPress site by sending and receiving data as JSON over standard HTTP requests.
Before the REST API, developers had to rely on admin-ajax.php, XML-RPC, or direct database access to move data in and out of WordPress programmatically. The REST API replaced that fragmented approach with a predictable, documented, HTTP-standard interface. It was introduced in WordPress 4.4 and reached full integration in WordPress 4.7 (December 2016).
The base URL for every WordPress REST API request follows this pattern:
https://yoursite.com/wp-json/wp/v2/The /wp-json/ prefix is the REST API discovery endpoint. A GET request to https://yoursite.com/wp-json/ returns a JSON index of all available routes on that installation.
Key Endpoints
The WordPress REST API organises content into routes. A route is a URI; an endpoint is the combination of that URI with an HTTP method (GET, POST, PUT, PATCH, DELETE). The same route can have multiple endpoints — GET /wp-json/wp/v2/posts lists posts, while POST /wp-json/wp/v2/posts creates one.
Here are the core routes available by default:
| Route | Resource | Common Methods |
|---|---|---|
/wp-json/wp/v2/posts | Blog posts | GET (list), POST (create) |
/wp-json/wp/v2/posts/{id} | Single post | GET, PUT, PATCH, DELETE |
/wp-json/wp/v2/pages | Pages | GET, POST |
/wp-json/wp/v2/pages/{id} | Single page | GET, PUT, PATCH, DELETE |
/wp-json/wp/v2/media | Media library items | GET, POST |
/wp-json/wp/v2/media/{id} | Single media item | GET, PUT, PATCH, DELETE |
/wp-json/wp/v2/categories | Categories | GET, POST |
/wp-json/wp/v2/tags | Tags | GET, POST |
/wp-json/wp/v2/users | Users | GET (authenticated), POST |
/wp-json/wp/v2/comments | Comments | GET, POST |
/wp-json/wp/v2/taxonomies | Registered taxonomies | GET |
/wp-json/wp/v2/types | Post types | GET |
/wp-json/wp/v2/search | Site-wide search | GET |
/wp-json/wp/v2/settings | Site settings | GET, POST (admin only) |
Plugins and themes can register their own routes using register_rest_route(). WooCommerce, for example, exposes its entire catalog, orders, and customer data under /wp-json/wc/v3/.
Public content (published posts, categories, tags) is readable without authentication. Private content, draft posts, user data, and write operations always require authentication.
Authentication Methods
The WordPress REST API supports three authentication approaches. The right choice depends on whether you are building a server-to-server integration, a user-facing app, or a same-origin JavaScript client.
1. Application Passwords (recommended for server integrations)
Introduced in WordPress 5.6 (December 2020), Application Passwords are the official method for authenticating external applications against the REST API without sharing your WordPress login password.
How they work:
- A WordPress administrator or any user with sufficient permissions generates an Application Password under Users → Edit User → Application Passwords.
- The consuming application sends the username and Application Password using HTTP Basic Authentication on every request.
- Each Application Password is independent and can be revoked without changing the main account password.
- Application Passwords work over HTTPS only — WordPress blocks them on plain HTTP by default.
A typical authenticated request using curl looks like this:
curl -u "username:xxxx xxxx xxxx xxxx xxxx xxxx" \
https://yoursite.com/wp-json/wp/v2/posts \
-X POST \
-H "Content-Type: application/json" \
-d '{"title": "New Post", "status": "draft"}'Application Passwords are the authentication layer that most REST API integrations — including MCP servers — use under the hood.
2. OAuth 1.0a (legacy, plugin-required)
WordPress core does not ship with OAuth 1.0a support. It is available via the official WP OAuth Server plugin maintained under the WordPress organization. OAuth 1.0a is more complex to implement and has largely been superseded by Application Passwords for most use cases.
3. Cookie Authentication + Nonces (JavaScript on the same origin)
When a JavaScript application runs within the WordPress admin (inside wp-admin or a plugin’s admin page), it can use the logged-in user’s session cookie directly. To protect against CSRF, every request must include a nonce — a short-lived token generated server-side with wp_create_nonce('wp_rest') and passed in the X-WP-Nonce header.
This is the authentication method WordPress itself uses for the block editor. It does not work for external applications because the cookie is scoped to the browser session.
Headless WordPress
“Headless WordPress” means using WordPress purely as a content management backend while serving the frontend from a separate technology — a React or Next.js app, a mobile app, or a static site generator. The WordPress REST API (or the newer GraphQL interface provided by WPGraphQL) is the data layer that connects them.
In a headless setup:
- Editors use the familiar WordPress admin to create and manage content.
- A separate frontend fetches content via the REST API and renders it in its own framework.
- The WordPress
wp-jsonAPI is public-facing and must be properly secured (rate limiting, HTTPS, read-only credentials where appropriate).
The REST API returns all standard post fields — id, title, content, excerpt, slug, status, date, modified, author, categories, tags, featured_media, and embedded link data. It also supports _embed as a query parameter to include related resources (author details, featured image data, terms) in a single request, reducing the number of round trips.
Limitations of the WordPress REST API
The REST API is powerful, but it has meaningful constraints that every developer hits eventually.
Custom post meta is not exposed by default
This is the most common frustration. WordPress stores plugin-specific data (SEO titles, custom fields, ACF values, WooCommerce attributes) in the wp_postmeta table as post meta. The REST API does not expose any of this by default. Each meta key must be explicitly registered using register_post_meta() with show_in_rest => true before it appears in API responses or accepts writes.
Many plugins — including Rank Math, AIOSEO, and ACF — do not register their meta with show_in_rest => true, which means their fields are invisible to the REST API. Writing to those fields via REST requires either custom endpoints or a bridge plugin. This is precisely the limitation that purpose-built MCP servers solve differently (more on this below).
No built-in batch requests
Each REST API call is a single HTTP request. If you want to update 50 posts, you make 50 requests. WordPress 5.6 did introduce a public batch endpoint at /wp-json/batch/v1, but individual routes must explicitly opt in to support batching — and no built-in core routes allowed batching at launch. For high-volume operations, this adds up.
Custom post types require explicit REST registration
Custom post types created with register_post_type() do not appear in the REST API unless show_in_rest => true is set during registration. Many older or poorly maintained plugins create post types without this flag, making their content inaccessible to the API.
Authentication complexity for user-facing apps
Application Passwords work well for server-to-server connections where you control both ends. For user-facing apps where you want to authenticate arbitrary WordPress users (across different sites), OAuth 1.0a is the correct approach but requires a plugin. WordPress core does not ship an OAuth server.
Performance under heavy query load
The REST API’s default query parameters (per_page, orderby, filter) cover most use cases, but complex queries can be slow on large databases without careful indexing. The API also adds overhead compared to direct WP_Query calls inside PHP.
REST API vs MCP: What’s the Difference?
The WordPress REST API and the Model Context Protocol (MCP) are not competitors — MCP sits on top of the REST API and extends it for AI use cases. Understanding the distinction matters when you are deciding how to connect AI to WordPress.
| WordPress REST API | MCP (via Easy MCP AI) | |
|---|---|---|
| Designed for | Developers writing HTTP clients | AI assistants discovering tools at runtime |
| Discovery | Manual — read the docs, construct URLs | Automatic — AI reads typed tool schemas |
| Custom post meta | Not exposed by default; requires register_post_meta() | Written directly to meta with permission checks |
| Batch operations | No native batch endpoint | Single AI prompt can drive multi-step sequences |
| Auth model | Application Passwords / OAuth / Nonces | OAuth 2.1 one-click (wraps REST auth underneath) |
| SEO plugin fields | Inaccessible unless registered with show_in_rest | Read/write directly (Yoast, Rank Math, AIOSEO) |
| WooCommerce data | Via /wp-json/wc/v3/ with API keys | 46 typed WooCommerce tools, no key management |
| Error handling | HTTP status codes + JSON error objects | Tool-level error messages AI can interpret |
| Cross-site | Each site is its own API | Each site is its own MCP server |
The key insight: MCP uses the WordPress REST API under the hood for standard operations, but adds a typed discovery layer so an AI assistant knows what tools exist, what parameters they take, and when to use them — without you writing any code. And where the REST API cannot reach (unregistered post meta), a server-side MCP plugin like Easy MCP AI writes the data directly using the same WordPress functions the admin uses.
We explained the MCP standard in full in our What Is MCP? guide, and the practical setup for WordPress in our Claude MCP WordPress integration guide.
Using the REST API with AI: Easy MCP AI
Easy MCP AI is a free, open-source WordPress plugin that turns your WordPress site into a fully compliant remote MCP server. Under the hood, it uses the WordPress REST API for standard reads and writes — and falls back to direct meta writes where REST cannot reach.
Its 215 tools (96 core WordPress tools plus tools for WooCommerce, ACF, BuddyPress, The Events Calendar, Yoast SEO, Rank Math, AIOSEO, Google Analytics, Google Search Console, SEMrush, and DataForSEO) are all typed, self-describing MCP tools. An AI assistant connected to Easy MCP AI can discover and call any of them from a plain-English prompt.
Practical examples of what this enables:
- “List all posts missing a meta description and generate one for each under 155 characters.” — reads post data via REST, writes SEO meta directly.
- “Update the Rank Math focus keyword on my 10 most recent posts to match their H1 headings.” — Rank Math fields are not REST-exposed by default; Easy MCP AI writes them directly.
- “Pull this month’s GSC organic clicks and write a 200-word traffic summary.” — combines the Google Search Console integration (6 tools) with a WordPress post creation call.
- “Find WooCommerce orders from last week that are still in ‘pending payment’ status and list them with customer email and total.” — hits WooCommerce data through typed MCP tools.
Security is handled with AES-256-GCM encryption, OAuth 2.1 one-click authorization, per-tool permission scoping, and WordPress capability checks on every operation. Everything runs on your own server.
Easy MCP AI connects to 16 AI clients including Claude Desktop, Claude Code, Cursor, Cline, Gemini CLI, GitHub Copilot, ChatGPT, n8n, Windsurf, and more. Setup is install → enable plugins → copy MCP URL → add as a custom connector in your AI client → OAuth authorize.
Key Facts
- The WordPress REST API base route is
/wp-json/wp/v2/— accessible on any WordPress site with pretty permalinks enabled - Routes are URIs; endpoints are a route + HTTP method combination; the two terms are not interchangeable
- Application Passwords were introduced in WordPress 5.6 (December 2020) — the official authentication method for external REST API integrations
- Cookie + nonce authentication is used by WordPress itself (the block editor) for same-origin JavaScript; it does not work for external apps
- Custom post meta is not exposed by default — each key requires
show_in_rest => trueregistration; most SEO plugin and ACF fields are blocked - Custom post types are not in the REST API by default —
show_in_rest => truemust be set at registration - There is no native batch endpoint in core for multi-object updates
- MCP (Model Context Protocol) sits on top of the REST API — it uses REST calls internally and adds a typed discovery layer for AI clients, plus direct meta writes where REST cannot reach
- Easy MCP AI exposes 215 tools across core WordPress, WooCommerce, ACF, BuddyPress, The Events Calendar, Yoast SEO, Rank Math, AIOSEO, Google Analytics, Google Search Console, SEMrush, and DataForSEO
Conclusion
The WordPress REST API is the backbone of every modern WordPress integration — from the block editor to headless frontends to AI agents. It is well-documented, stable, and powerful. But it has real limits: custom post meta is invisible to it by default, batch operations require workarounds, and the authentication story for user-facing apps involves a plugin.
For AI use cases in 2026, those limits matter. MCP-based tools like Easy MCP AI close the gaps — using the REST API where it works and writing directly where it does not, all wrapped in a typed, AI-native interface that any MCP-capable client can discover and drive.
→ Get Easy MCP AI from the WordPress plugin directory
Official Sources
- REST API Handbook — WordPress Developer Resources (developer.wordpress.org) — official handbook; describes JSON data format, public vs. authenticated access
- Key Concepts — REST API Handbook (developer.wordpress.org) — authoritative definitions of routes, endpoints, requests, responses, and schema
- Application Passwords: Integration Guide — Make WordPress Core (make.wordpress.org, November 5, 2020) — confirms Application Passwords introduced in WordPress 5.6
- REST API Reference — WordPress Developer Resources (developer.wordpress.org) — full endpoint reference for all default routes
- Easy MCP AI — WordPress Plugin Directory (wordpress.org)