What Is the WordPress REST API?
The WordPress REST API is a built-in interface that lets other software read and write a WordPress site's content over HTTP using JSON. Instead of only rendering pages through PHP themes, WordPress exposes posts, pages, media, and custom content at predictable URLs under /wp-json/, which apps, JavaScript front ends, and external systems can request. It powers the block editor, headless WordPress builds, mobile apps, and integrations with CRMs. Available since WordPress 4.7, it turns WordPress into a flexible content backend.
- What it is
- An HTTP/JSON interface to read and write WordPress content (WordPress Developer docs)
- Core since
- The content endpoints merged into WordPress core in version 4.7 (2016) (WordPress Developer docs)
- Base route
- Endpoints live under yoursite.com/wp-json/wp/v2/
- Data format
- Requests and responses use JSON over standard HTTP methods (GET, POST, etc.)
- Auth for writes
- Reading public data is open; creating or editing requires authentication
What the REST API is #
The WordPress REST API is a standardized way for other programs to talk to a WordPress site over the web. REST is a common architectural style for web services, and an API is an interface that lets software exchange data. Put together, the WordPress REST API exposes your site's content, posts, pages, media, categories, users, and more, at predictable web addresses under /wp-json/, returning and accepting data in JSON, the lightweight text format that dominates modern web communication. This means WordPress is no longer just a system that renders HTML pages through PHP themes; it can also serve its content as structured data that JavaScript apps, mobile apps, and external systems consume and update. Introduced into core with WordPress 4.7 in 2016, the REST API underpins the block editor and enables architectures that were previously awkward in WordPress. For businesses building anything beyond a traditional website, such as custom integrations through /services/api-crm-integrations, the REST API is often the doorway that makes WordPress content programmatically accessible.
How REST APIs work in plain terms #
To understand the WordPress REST API, it helps to grasp the basics of how such interfaces operate. A client, a browser script, an app, or another server, sends an HTTP request to a specific URL, called an endpoint, using a method that signals intent: GET to read data, POST to create, PUT or PATCH to update, DELETE to remove. The server responds with data, usually in JSON, and a status code indicating success or failure. In WordPress, requesting the posts endpoint with GET returns a JSON list of posts; sending a POST with the right data and authentication creates a new post. This request-and-response pattern is the same one that powers most modern web and mobile applications. Because it is standardized, developers using almost any programming language can work with WordPress content. This universality is why the REST API is central to modern /services/web-app-development, letting teams build custom experiences on top of WordPress content using tools and frameworks outside the traditional PHP-theme world.
The structure of WordPress endpoints #
WordPress organizes its REST API under a clear, predictable structure. The base is yoursite.com/wp-json/, and the core content routes live under wp/v2/, so posts are at /wp-json/wp/v2/posts, pages at /wp-json/wp/v2/pages, media at /wp-json/wp/v2/media, and so on. You can request a specific item by adding its ID, and refine results with query parameters for searching, filtering, ordering, and pagination. Custom post types and taxonomies can appear here too when registered with show_in_rest enabled, which is why that setting matters when modeling content. Plugins and developers can also register their own custom endpoints for specialized data. The example below shows a simple request and the shape of the JSON it returns. This orderly, self-describing structure makes the API approachable: once you know the pattern, you can explore a site's content programmatically. For projects connecting WordPress to other platforms, understanding these routes is the starting point of the integration work handled in /services/api-crm-integrations.
# Fetch the 3 most recent posts as JSON
curl "https://yoursite.com/wp-json/wp/v2/posts?per_page=3"
# A trimmed sample of the JSON response:
# [
# {
# "id": 128,
# "date": "2026-07-01T10:00:00",
# "slug": "summer-hours",
# "title": { "rendered": "Our New Summer Hours" },
# "excerpt": { "rendered": "<p>We are now open later...</p>" }
# }
# ]Powering the block editor and beyond #
The most visible everyday use of the REST API is the WordPress block editor itself. When you edit a post, the editor is a JavaScript application that reads and saves your content through the REST API rather than the old page-reload model. This is why custom post types must have show_in_rest enabled to work in the block editor, without it, they fall back to the classic editor. The same API that powers editing also enables far more: mobile apps like the official WordPress app manage content through it, and developers build custom admin interfaces and dashboards on top of it. Because the editor and apps rely on the REST API, it is a load-bearing part of modern WordPress, not an optional extra. Recognizing this helps explain behavior that puzzles owners, such as why a certain setting affects both the editor and external access. For teams doing serious /services/wordpress-development, the REST API is woven throughout the platform, quietly enabling much of what feels like ordinary WordPress functionality today.
Headless WordPress explained #
One of the most significant uses of the REST API is headless WordPress. In a traditional setup, WordPress both stores content and renders the public pages through its PHP themes. In a headless setup, WordPress is used only as the content backend, the head, meaning the visual front end, is removed, and a separate application, often built with a JavaScript framework like React or Next.js, fetches content through the REST API and renders the site. This decoupling can offer performance benefits, front-end flexibility, and the ability to feed the same content to multiple destinations, a website, an app, a kiosk, from one WordPress source. It also adds complexity and cost, since you now maintain two systems, and some WordPress conveniences, like themes and many plugins' front-end features, no longer apply directly. Headless is powerful for the right project but overkill for a simple brochure site. Weighing whether a headless architecture suits your goals is a core decision in ambitious /services/web-app-development, where the flexibility can justify the added engineering.
Authentication and security #
By default, the WordPress REST API lets anyone read public content, the same content visitors could see anyway, without logging in. But creating, editing, or deleting content, and reading private data, requires authentication so only authorized users can make changes. WordPress supports several authentication methods, including application passwords built into core, which let an external app act as a user with a dedicated credential, as well as OAuth and other schemes via plugins. Because the API can expose and modify data, security matters: sites should ensure sensitive endpoints are protected, limit what unauthenticated requests can access, and keep WordPress updated, since API vulnerabilities have appeared historically and were patched. Rate limiting and monitoring help against abuse. For any integration that writes to a site, using proper authentication and least-privilege credentials is essential, part of the discipline in /services/api-crm-integrations and broader /services/website-security. Treating the REST API as a real interface to your data, secured accordingly, prevents it from becoming an overlooked entry point for attackers.
Common integrations the REST API enables #
The REST API opens WordPress to a wide range of integrations that businesses find valuable. A CRM can pull form submissions or push contact updates; an email marketing platform can sync subscribers; an inventory system can update product data on a WordPress store; a mobile app can display and manage site content. Custom dashboards can aggregate WordPress data alongside other sources, and external services can publish content into WordPress automatically. Because the API speaks standard JSON over HTTP, it connects with the vast ecosystem of tools that support web APIs, including automation platforms that link apps without custom code. This connectivity is exactly what turns a website into part of a larger business system rather than an island. Designing these connections reliably, handling authentication, error cases, and data mapping, is the substance of /services/api-crm-integrations work. For a growing business, the REST API is often the mechanism that lets the website share data with the other software the company already runs, reducing duplicate data entry and manual syncing.
When the REST API matters to your project #
Not every site needs to think about the REST API directly; for a standard WordPress site, it quietly powers the editor and you never touch it. It becomes a deliberate consideration when your project involves custom integrations, a mobile app, a headless front end, or feeding content to systems beyond the website. If you plan to connect WordPress to a CRM, sync data with other platforms, or build a custom application on top of your content, the REST API is likely central, and modeling your content with show_in_rest enabled from the start matters. If you are simply running a marketing or brochure site, you can rely on it working behind the scenes without special attention. Knowing where your project sits on this spectrum guides early decisions. A planning conversation, sometimes beginning with a /free-website-audit of your current setup and goals, clarifies whether the REST API will be a quiet enabler or a starring player in your build, and shapes the architecture accordingly.
FAQ
What is the WordPress REST API used for?
It lets other software read and write a WordPress site's content over HTTP using JSON. It powers the block editor, enables headless WordPress where a separate front end renders the content, drives mobile apps, and supports integrations with CRMs, email tools, and other systems. In short, it makes WordPress content programmatically accessible to apps and services beyond the traditional website.
How do I access the WordPress REST API?
Public content is available at predictable URLs under yoursite.com/wp-json/, with core routes under wp/v2/, such as /wp-json/wp/v2/posts for posts. You can open these in a browser or request them with tools like curl to see JSON. Creating or editing content requires authentication, for example WordPress's built-in application passwords, so only authorized users can make changes.
What is headless WordPress?
Headless WordPress uses WordPress only as a content backend while a separate application, often built with a JavaScript framework, fetches that content through the REST API and renders the public site. It can improve front-end flexibility and let one content source feed multiple destinations, but it adds complexity and cost, so it suits ambitious projects more than simple brochure sites.
Is the WordPress REST API a security risk?
It is a real interface, so it should be secured, but reading public content through it exposes nothing visitors could not already see. Writing or accessing private data requires authentication. Keeping WordPress updated, protecting sensitive endpoints, using least-privilege credentials, and monitoring for abuse keep it safe. Historic API vulnerabilities were patched, which is why staying current matters.
Do I need to enable the REST API?
It is enabled by default in modern WordPress and powers the block editor, so it is already active. You generally do not turn it on. For custom post types to appear in the API and the block editor, though, you set show_in_rest to true when registering them. Some sites restrict certain endpoints for security, but the API itself is built in.
Can the REST API connect WordPress to my CRM?
Yes. Because the REST API exchanges JSON over standard HTTP, it can integrate WordPress with CRMs, email platforms, and other systems, pushing form submissions, syncing contacts, or updating content automatically. Designing these connections reliably, with proper authentication and data mapping, is exactly the kind of work handled in API and CRM integration projects, turning your site into part of a connected business system.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?