Quick answer: The WordPress REST API lets other applications read and write your WordPress content over HTTP using JSON. Since WordPress 4.7, core includes endpoints for posts, pages, media, users, categories, tags and comments, and you can register your own. That makes it possible to build headless front ends, mobile apps, integrations with CRMs and other systems, internal dashboards and custom admin tools, all using WordPress as the content back end.
For most of its history, WordPress has been a system that stores content and renders it as HTML pages through a theme. The REST API changes that. Your content becomes available as structured data at predictable URLs, so anything that can make an HTTP request can use it. A JavaScript front end, an iPhone app, a sales system or a small script on a server can now talk to WordPress directly.
This guide explains how the API works and the kinds of projects it makes practical.
What the REST API is
An API (application programming interface) is a defined way for one piece of software to talk to another. If you are new to the idea, our explainer on what an API is covers the basics. REST is a style of API that uses ordinary HTTP methods on resource URLs:
- GET to read data.
- POST to create data.
- PUT or PATCH to update data.
- DELETE to remove data.
On a WordPress site, the API lives under /wp-json/. The core content endpoints are in the wp/v2 namespace, for example:
- /wp-json/wp/v2/posts for posts
- /wp-json/wp/v2/pages for pages
- /wp-json/wp/v2/media for the media library
- /wp-json/wp/v2/categories and /wp-json/wp/v2/tags for taxonomies
- /wp-json/wp/v2/users for users
- /wp-json/wp/v2/comments for comments
Requesting /wp-json/wp/v2/posts returns the latest published posts as JSON, including title, content, excerpt, date, author ID, featured media ID, categories and links to related resources. Query parameters let you filter and paginate: per_page, page, search, categories, orderby and more.
A short history
The REST API started as a feature plugin. The infrastructure was merged into core in WordPress 4.4, and the content endpoints followed in WordPress 4.7 in December 2016. Since then, every standard WordPress site has had the API available by default. The new Gutenberg editor, currently in testing as a plugin, is built on top of it, which is a good sign that the API is central to where WordPress is heading.
Authentication and permissions
Public data, such as published posts and pages, can be read without logging in. Anything that changes data, or reads private data, needs authentication. The options are:
- Cookie authentication with a nonce. Used by JavaScript running inside WordPress itself, such as a custom admin screen or a theme feature for logged-in users.
- OAuth 1.0a. Available through the official OAuth server plugin, suited to third-party apps that act on behalf of users.
- Application passwords. A feature plugin that issues separate passwords for API access, so you never share a user’s main password with an external system.
- JWT authentication. Popular plugins issue JSON Web Tokens for headless and mobile apps.
- Basic authentication. Fine for local development, but only use it over HTTPS and preferably not in production with real user passwords.
The API respects WordPress roles and capabilities. A user who cannot publish posts in the dashboard cannot publish them through the API either. When you build custom endpoints, you define a permission callback that checks capabilities before doing anything.
Extending the API
Core endpoints are a starting point. Most real projects extend them.
Custom post types and taxonomies
Register a custom post type or taxonomy with show_in_rest set to true and it gets its own endpoints automatically. A “listings” post type becomes /wp-json/wp/v2/listings, with the same filtering and pagination as posts.
Custom fields
Post meta is not exposed by default. You can expose specific fields with register_meta (with show_in_rest) or add computed fields to responses with register_rest_field. Advanced Custom Fields users often add a companion plugin to include ACF fields in responses. Be selective: only expose the fields a client needs.
Custom endpoints
When your data does not map neatly onto posts, use register_rest_route to create your own endpoints with their own namespace, for example /wp-json/mycompany/v1/quotes. You control the arguments, validation, permission checks and response shape. This is the right approach for business logic: calculating a quote, checking stock, or returning a combined dataset for a dashboard.
Good API design still applies inside WordPress: clear resource names, versioned namespaces, consistent errors and sensible pagination. Our guide to REST API design covers these principles.
What you can build
Headless or decoupled websites
In a headless setup, WordPress manages content while a separate front end, often built with React, Vue or a static site generator, fetches it through the API and renders the pages. Editors keep the familiar dashboard, and developers get full control over the front end and its performance. The trade-offs are real: you lose some theme and plugin features that rely on PHP templates, previews take extra work, and SEO basics like meta tags and sitemaps have to be rebuilt in the front end. Our article on the headless CMS approach discusses when it makes sense.
Mobile apps
A news publisher, membership organisation or event business can use WordPress as the back end for an iOS or Android app. The app pulls posts, events or courses through the API, and content editors publish once for both the website and the app.
Integrations with other systems
The API makes it easier to connect WordPress with the rest of your business:
- Push new leads from WordPress forms into a CRM, or pull product data from an ERP into custom post types.
- Publish job listings from an HR system straight onto the careers page.
- Sync events from a booking platform so the website calendar stays current.
- Send content to an email platform or a digital signage screen.
Many of these can also be done with automation tools such as Zapier, which talk to WordPress through the same API. For more complex flows, a custom integration gives you more control over error handling and data mapping.
Custom admin tools and dashboards
Inside WordPress, the API makes interactive admin screens much easier to build. A JavaScript interface can load and save data without page reloads, giving editors faster tools for tasks like bulk editing product information, moderating submissions or reviewing orders.
Multi-site content sharing
Organisations with several WordPress sites can use the API to share content between them: a central news site feeding regional sites, or a parent brand pulling posts from a franchise network.
Single-page applications on top of a regular site
You do not need to go fully headless to benefit. A normal theme can include interactive features, such as a filterable directory, a store locator or a live search, that fetch data from the API on the page.
Performance and security considerations
- Cache where possible. API responses can be cached at the server or CDN level, just like pages. Uncached, heavy queries can be slow.
- Limit what you expose. Only expose fields that clients need. Review the users endpoint, which by default lists authors with published posts; some sites restrict it to reduce user enumeration.
- Validate and sanitise input. Custom endpoints should validate every argument and check permissions in the permission callback.
- Use HTTPS. Any authenticated request must travel over HTTPS.
- Rate limiting. If you expose write endpoints publicly, consider rate limiting at the server or firewall.
FAQ
Can I turn off the REST API?
You can restrict it, but disabling it entirely can break plugins and, soon, the new editor. Restricting sensitive endpoints to logged-in users is a safer approach.
Do I need a developer to use the REST API?
For reading public content into a simple tool, not always. For custom endpoints, authentication and headless builds, yes, you need someone comfortable with PHP and JavaScript.
Is the REST API slower than a normal page load?
Not inherently. A lean API request can be faster than rendering a full theme page. Large responses with many embedded resources can be slow, so request only what you need.
Building on WordPress as a platform
The REST API turns WordPress from a website builder into a content platform that other software can use. That opens up apps, integrations and front ends that would have needed a separate system a few years ago. If you have a project in mind, our custom development team builds API-driven WordPress solutions and integrations.
