The WordPress REST API gives applications a structured way to read from and interact with a WordPress website.
You do not need to understand the REST API to publish pages, edit posts or manage an ordinary WordPress website. But if you want WordPress to exchange data with another website, app or service, it is useful to understand what the API does.
This guide explains the basics without assuming you are a developer. We will look at APIs, REST, routes, endpoints, HTTP methods, JSON and authentication, then try a few safe examples using a WordPress website.
What is the WordPress REST API?
The WordPress REST API is an interface that allows software to communicate with WordPress using HTTP requests.
Instead of loading a normal webpage designed for a person to read, an application can request structured WordPress data such as posts, pages, categories or other content.
WordPress returns that information in a format that software can understand and process. Applications can also use the REST API to perform authorised actions, such as creating or updating content, when the request has the necessary authentication and permissions.
The REST API has been part of WordPress core for many years and is now an established part of the platform. It is used by WordPress itself as well as by plugins, external applications and custom integrations.
What is an API?
API stands for Application Programming Interface.
An API provides a defined way for one piece of software to communicate with another.
Imagine that one system needs a list of the latest articles from your WordPress website. Rather than trying to extract those articles from the visible webpage, it can ask WordPress for the data through the API.
The API defines what can be requested, how the request should be made and what kind of response the application can expect.
APIs are widely used across the web. Payment services, email marketing platforms, analytics systems, mobile apps and many other tools provide APIs so other software can interact with them.
What does REST mean?
REST stands for Representational State Transfer. It describes an architectural approach commonly used when designing web APIs.
For a beginner, the important part is that a REST API uses familiar web technologies. A client sends an HTTP request to a particular address, and the server sends a response.
REST itself is not a security system. Authentication, permissions, HTTPS and other security controls determine whether a particular request should be allowed.
The WordPress REST API follows REST-style principles and exposes resources such as posts, pages, users and categories through predictable URLs.
Routes and endpoints
Two terms you will see frequently in the WordPress REST API documentation are route and endpoint.
A route is the URI used to identify a resource. For example:
/wp/v2/postsAn endpoint combines a route with the HTTP method and the code that handles that particular type of request.
That means the same route can support more than one operation. A GET request might retrieve posts, while an authenticated POST request to the same route can create a new post.
On a typical WordPress site, the REST API is available beneath:
https://example.com/wp-json/The wp/v2 part you will see in many WordPress endpoints is the namespace used by the core version 2 REST API routes.
GET, POST, PUT, PATCH and DELETE
REST APIs use HTTP methods to indicate what kind of action a request is trying to perform.
- GET retrieves a resource or collection of resources.
- POST commonly creates a new resource.
- PUT can update or replace an existing resource.
- PATCH can apply a partial update when an API supports it.
- DELETE requests the removal of a resource.
The exact methods supported depend on the endpoint.
It is also important not to confuse these API methods with ordinary actions you perform in a browser. Logging into WordPress or editing a user does not automatically mean your browser is using the WordPress REST API in the simple way described above.
What does the WordPress REST API return?
The WordPress REST API normally returns data as JSON.
JSON stands for JavaScript Object Notation. It is a text-based format used to represent structured information in a way that is relatively easy for both humans and software to read.
A response for a WordPress post can contain information such as its ID, publication date, slug, title, content, author and links to related resources.
The raw response may look complicated at first because it contains more structure and metadata than the visible article itself. Browser developer tools, API clients and JSON formatting extensions can make it easier to inspect.
Trying the WordPress REST API safely
You can explore some WordPress REST API endpoints without writing code.
For example, on a typical WordPress website you can request a list of published posts using:
https://example.com/wp-json/wp/v2/postsReplace example.com with the domain of the WordPress site you want to inspect.
If the endpoint is publicly available, your browser should display a JSON response containing published posts.
You can use similar endpoints for other public WordPress content:
/wp-json/wp/v2/postsfor posts/wp-json/wp/v2/pagesfor pages/wp-json/wp/v2/categoriesfor categories/wp-json/wp/v2/tagsfor tags
The exact data available depends on the website, its content and any plugins or custom code that register additional REST API routes.
Simply viewing a public endpoint is normally a read-only operation. You are requesting data rather than changing anything on the website.
Filtering and limiting results
REST API requests can include parameters that change what WordPress returns.
For example, this requests five posts:
https://example.com/wp-json/wp/v2/posts?per_page=5You can also request a particular page of results:
https://example.com/wp-json/wp/v2/posts?per_page=5&page=2Different endpoints support different parameters, so the official WordPress REST API reference is the best place to check what is available.
For example, the posts endpoint supports parameters for areas such as pagination, search, authors, categories, tags and publication dates.
Authentication and permissions
Reading publicly available content is very different from making changes to a WordPress website.
Requests that create, update or delete content normally need to be authenticated, and the authenticated WordPress user must have permission to perform the requested action.
For example, an anonymous visitor may be able to retrieve a published post with a GET request, but they cannot simply send a POST request and create new content.
WordPress checks authentication and user capabilities before allowing protected REST API operations.
Authentication inside WordPress
When the REST API is being used from within WordPress by a logged-in user, WordPress can use its normal cookie-based authentication together with a nonce to verify the request.
This is commonly used by WordPress itself and by plugins or admin interfaces that communicate with REST API endpoints.
Application Passwords
For external applications, WordPress supports Application Passwords.
An Application Password is a separate credential created for an application rather than giving that application your main WordPress account password.
It can be revoked independently if you stop using the integration or believe the credential has been exposed.
Application Passwords should still be treated as sensitive credentials. They should only be sent over HTTPS and should never be published in code repositories, webpages or other public locations.
Can the REST API expose private WordPress data?
The REST API does not automatically make every piece of WordPress data public.
WordPress endpoints use permissions to determine what a particular request is allowed to access.
Publicly published content may be available without authentication because that information is already intended to be public. Private content, administrative settings and protected operations generally require an authenticated user with the necessary capabilities.
Plugins and custom development can also register their own REST API routes, so developers should make sure those routes include appropriate permission checks rather than assuming WordPress will secure custom endpoints automatically.
What happens when an API request fails?
An API request does not always succeed.
The server may return an HTTP status code and a JSON error response explaining what went wrong.
Common reasons include requesting something that does not exist, sending invalid data, failing authentication or attempting an action the current user is not allowed to perform.
Understanding the status code and error response is an important part of troubleshooting an integration.
What can you use the WordPress REST API for?
The REST API becomes useful when WordPress needs to share data with another application or when you want to build an interface that does not rely entirely on the normal WordPress front end.
Common uses include:
- Displaying WordPress content inside a mobile app
- Sending content to another website or service
- Building a custom front end that uses WordPress as the content management system
- Creating integrations between WordPress and external business systems
- Automating publishing or content-management tasks
- Allowing plugins and custom admin interfaces to exchange structured data with WordPress
The REST API can also be extended. Plugins and custom code can register new routes for application-specific data and actions.
That flexibility is one reason WordPress can be used as more than a conventional website publishing system.
Can WordPress be used as a headless CMS?
Yes. One common use of the REST API is a headless WordPress setup.
In a traditional WordPress website, WordPress manages both the content and the webpages visitors see.
In a headless setup, WordPress can continue to manage the content while a separate application handles the front end. That application can request content from WordPress through the REST API and decide how to display it.
This approach can be useful for some projects, but it also adds development and maintenance complexity. A conventional WordPress website is often simpler when there is no strong reason to separate the front end from WordPress.
Do you need to be a developer to use the REST API?
You do not need to be a developer to understand the REST API or inspect public endpoints.
Typing a public GET endpoint into your browser and looking at the JSON response is a useful way to understand what WordPress exposes.
However, building a reliable integration usually requires some technical knowledge.
Once you start authenticating requests, sending data, handling errors or connecting WordPress to another application, you need to think carefully about security, validation, permissions and what happens when either system changes.
So the REST API is approachable for beginners, but that does not mean every API integration is a no-code task.
Where should you learn more?
The official WordPress REST API Handbook is the best reference when you want to go beyond the basics.
It documents the core routes, endpoint behaviour, authentication, requests, responses and the APIs developers can use to extend WordPress.
The REST API reference is particularly useful when you need to know which methods and parameters a particular WordPress resource supports.
Understanding the WordPress REST API
The WordPress REST API gives software a standard way to communicate with WordPress over HTTP.
Public GET requests can retrieve information such as published posts and pages, while protected operations require authentication and the appropriate WordPress permissions.
Routes identify resources, HTTP methods describe the requested operation, and WordPress normally returns the result as JSON.
For most website owners, understanding those concepts is enough to recognise what the REST API is doing and when it might be useful.
If you need WordPress to connect with another system or require help with custom functionality, Newt Labs provides WordPress website changes and one-off WordPress support.
