You want to use your WordPress content in another application, build a connection with an external system, or you came across the term in some documentation and are wondering what exactly is “open” on your site. In all three cases, you’ll end up at the REST API: the built-in feature that allows WordPress to make its content and functions available to other software. Every modern WordPress site has it built in and even uses it internally, even if you’ve never consciously interacted with it. In this article, we’ll break down the API: what it is, how to interact with it, how access permissions work, and how it’s used in practice.
What a REST API Actually Is
An API (application programming interface) is a standardized way for software to communicate with other software without the need for a human using a browser. REST is the most commonly used style for this: you request data via standard web addresses and receive it back as JSON, a structured text format that any programming language can read. Specifically: where you, as a visitor, open yourdomain.nl/blog and see a formatted page, an application can request yourdomain.nl/wp-json/wp/v2/posts and receive the same blog posts as raw data: title, content, date, author—all neatly structured. Feel free to try that URL on your own site; what you’ll see is the REST API in action.
Endpoints: the addresses of your data
Each type of data has its own address within the API—an endpoint. Everything starts at /wp-json/, followed by the routes: /wp/v2/posts for posts, /wp/v2/pages for pages, /wp/v2/media for media files, /wp/v2/users for users, and so on. You can use parameters to filter and sort data; for example, ?per_page=5&orderby=date retrieves the five most recent posts. Plugins can add their own endpoints: WooCommerce, for example, provides a complete API for products and orders. It’s also important for developers to know that you can register your own endpoints using custom code, allowing WordPress to serve as a content source for virtually any application.
Reading is allowed, but writing requires a key: authentication and permissions
Here’s the part every site owner should know, even those who never write a single line of code. The API follows the same permissions structure as your site itself. Everything that’s publicly available on your site is also publicly accessible via the API: your published posts and pages can be retrieved without logging in. This isn’t a security vulnerability—it’s by design; it’s the same information that every visitor can already see. Anything beyond that—such as creating, editing, or deleting content, or viewing draft texts—requires authentication: the requester must prove their identity and is then granted exactly the permissions associated with their user role.
The standard way to do this is with app passwords: separate passwords for each connection, which you create under "Users," then your profile, in the "App Passwords" section. The major advantage over your regular password is that you give each integration its own key, can see which ones exist, and can revoke one without affecting the rest. Two best practices ensure this remains secure. For integrations, create a separate user with no more permissions than the integration requires: a service that only posts messages should be given an author role, not an administrator role. And review your application passwords periodically, just like your user list; a forgotten connection with administrative privileges is exactly the kind of silent backdoor you want to avoid. This review is part of the normal management of your site, as described in our A Complete Guide to WordPress Management.
What the API Is Used For in Practice
The applications fall roughly into three groups. Integrations: external systems that communicate with your site, such as accounting software that retrieves orders, a newsletter service that fetches new posts, or automation platforms like Zapier and Make that connect WordPress to hundreds of other services. Automation: custom scripts that, for example, publish content from a spreadsheet or synchronize data between systems on a daily basis. And headless sites: setups where a separate front end retrieves all content via the API, and WordPress serves purely as an administration environment. Also good to know: the block editor in your dashboard uses the API internally for virtually everything. If the editor suddenly stops working while the rest of the site functions normally, a blocked API (often caused by a security plugin or firewall rule) is a common culprit.
Should you disable the API?
This question comes up regularly in security advisories, so here’s an honest answer: no, completely disabling it is not recommended, because your dashboard and many plugins rely on the API itself. What might be a good idea, however, is to restrict the /wp/v2/users endpoint for unauthenticated users, since that reveals usernames that can be exploited in credential stuffing attacks. Most security plugins offer a handy option for this. Furthermore, the API is only as secure as your usernames and passwords, so that’s where your real security work lies.
At Surver: if you’re going to experiment with API integrations or your own scripts, don’t do it directly on your live site—do it on a copy instead—and make sure there’s a recent restore point. With our managed packages, daily automatic backups are available for this purpose, and you can read about how to set up a test copy yourself in our A Complete Guide to WordPress Backups and Migration. Our support team is available seven days a week to help troubleshoot if a connection is behaving unusually.
From Understanding to Application
For most site owners, the main benefit of this article is understanding: you now know what’s exposed via /wp-json, how to securely set permissions on links, and why that particular automation works the way it does. If you want to start building on your own, the official WordPress REST API documentation is the next step. And if you’re just building a good site without any integrations, there’s nothing to worry about: the API quietly does its job in the background, while you can continue working on the front end using our A Beginner's Guide to Creating a Website with WordPress.
