One of the areas where WordPress shines is content management. This is also corroborated by the fact that it is the world’s leading Content Management System, or CMS, by numbers.

The most popular way of displaying the content hosted by WordPress is through a frontend, like through blog posts and pages. That is wonderful for human visitors but there are other ways of consuming that content –– for example, web APIs.

In this article, we’ll explore how we can leverage WordPress in order to power a central API for projects like phone apps, browser extensions, or the frontends of other WordPress sites!

Following along

All the steps described in this article were made in WordPress Playground. If you want to see the end result and maybe sometimes skip ahead as we go, download this ZIP file, and perform these steps:

What is a web API?

API stands for Application Programming Interface and it’s a way for software applications to communicate with each other in a standardized fashion. A web API is simply one that is accessed through “the internet” –– for example, by entering a certain URL in your web browser.

There are multiple types of web APIs, and one common way to group them is the protocol they use. In this article, we’ll be implementing two APIs, one based on the REST protocol, and another based on the GraphQL protocol. Other protocols you might have heard of include SOAP, RPC, or gRPC.

WordPress actually includes a built-in REST API which powers the Gutenberg Block Editor. As of October 2024, the popular WPGraphQL plugin has become a canonical plugin paving the road for an official GraphQL API as well.

What data we’ll be modeling

By the end of this article, we’ll have built a WordPress site that allows users to login in order to add/update/delete data entries which will be queryable both via REST routes and a GraphQL endpoint.

The data entries will collectively represent a company’s organizational chart –– things like employees, teams, and offices. While a little bland, the concepts can be applied to absolutely anything else.

Optional: Trimming down the frontend

While an optional step, it makes a lot of sense to do this if your site won’t be serving any content via pages but exclusively through APIs.

Once you have a hosted WordPress website, you can start by installing a minimalist WordPress theme like Blank Canvas and deleting every single demo post and page on your site. Continue by using the site editor to include information on the homepage for visitors who find it unintentionally.

For example, add your business’ name and logo, and tell them that they probably landed there in error. You can also include a button linking to the admin area for maintainers of the content. Something along the lines of:

One way to prevent your site from being found in search engine results is by checking the Discourage search engines from indexing this site in your site’s settings.

If you would rather fully lock down the frontend and not even have the homepage described above, you can add the following code snippet either to a plugin like Code Snippets or to your child theme’s functions.php file:

Custom post types and taxonomies

Now it’s time to focus on the website’s admin area and the data modeling part of this tutorial. The most straightforward way of compartmentalizing your data is by using WordPress’ built-in functionality of custom post types and custom taxonomies.

While there are many ways to do this, for the purposes of this tutorial, we’ll organize our data like this:

In order to create these custom data types, you can either add custom code to your site, or use a plugin (like in this video). A very popular plugin for creating custom post types and taxonomies using the admin interface is Custom Post Type UI – and that is what we’ll be using in this tutorial.

Here is the JSON configuration for importing the data into your installation:

At this point, your WordPress admin interface might look something like this:

To Gutenberg or not to Gutenberg

The Gutenberg block editor is functional, adaptable, and easy to use, and you should be using it to edit your traditional WordPress posts and pages. However, when it comes to CPTs without a frontend, there might not be any content to warrant the use of a performant editor like Gutenberg.

If you are positive that all of the information you need is not HTML-based, then it might make sense to disable Gutenberg for these CPTs and default back to the classic post editor that was the standard before WordPress 5.0.

The simplest way to disable Gutenberg support for a CPT is to set the show_in_rest argument to false when registering it (as we’ve done above).

Alternatively, if you want to keep the built-in REST routes that WordPress provides for every CPT, you can add this code to your child theme:

Custom Fields

Now that we have our basic data types in place, we need to start populating them with entries. Before we do that, we need to ensure that we can record all the necessary data on each entry, and for that we will need to build custom fields.

The easiest way to add custom fields to your custom post types is to register them with custom-fields support. When you then edit a post, it will include a metabox like this:

While this type of “key-value” interface can be enough, you might want to build a more user-friendly interface with fields like checkboxes, dropdowns, media selectors, and so on.

A popular way to add those types of custom fields is the Meta Box plugin, which, as mentioned above, is what we’ll be using in this tutorial. Using their online custom fields generator, we got the PHP code needed to register the fields we wanted and then added them to Code Snippets.

Using a fake data generator, we populated the custom post types with a bit of seed data:

Other UI customizations

While we won’t explore any further UI customization options in this tutorial, we wanted to note that it’s possible to use various WordPress filters to tweak things like:

Access control

Before we start looking into making the data available via API, it’s time to think about who should have access to it.

The custom post types and taxonomies mentioned above were registered in such a way that any logged-in user with the ability to edit regular WordPress blog posts will also have the ability to edit these. However, it’s possible to make that much more granular.

You can create custom user roles with custom capabilities in order to ensure that the UI is as clean-as-possible in order to promote focused-work for the users doing the data maintenance. This is particularly important if you anticipate a very high number of entries, especially on an ongoing basis.

While it is possible to control this entirely with custom code, a way to maintain a simpler overview of access management is provided by Access Policies implemented by the Advanced Access Manager plugin.

For example, you can create a separate access policy for each CPT you create. Then you may assign the policy either to a role or to individual users in order to maintain full control over who may add new Employee entries or even just edit existing ones. Deleting entries can be a capability reserved only for administrators.

Here is an example of how a policy named Employees CPT – Full Control and assigned only to Administrator users can look like:

Here is an example of what the admin interface can look like for a dummy operator user that has the Data Entry Operator user roles (cloned from the Subscriber role) with two AAM Access Policies attached – one for each custom CPT:

Notice how the lack of most menu items makes it easier to focus solely on the data-entry aspect. The policies can be made more granular, for example, to also restrict who may delete an entry or create new ones.

Custom REST routes

While WordPress will automatically create REST routes for every CPT as long as it is registered with the show_in_rest argument set to true, you can also create your own custom rest routes that are better suited for serving the CPT content in a way that makes more sense to your use-case.

The easiest and most standard way to achieve this is by extending one of the REST API controller classes. For maximum control over the output, you may want to extend the base WP_REST_Controller class itself.

You can choose to have your routes publicly accessible if the permission_callback argument is set to the __return_true function or you can choose to lock down calls using any permission scheme you want.

The recommended way of locking down access is behind a capability check, i.e. a call to current_user_can. You can use the AAM Access Policies mentioned above to grant or withdraw permission from individual roles or users, and you can use WordPress’ application passwords to authenticate API requests.

Hint: even if you decide that GET (read) requests should/can be publicly available, we still recommend that any POST // PUT // DELETE (create, update, delete) requests always be guarded by a current_user_can check.

Here is a REST controller that we added to Code Snippets in order to be able to list the employees on the site and fetch them by ID:

Testing your REST routes

Your custom REST routes will be available under <your-domain>/wp-json/<route_namespace>/<route>. For example, the path for retrieving the list of employees could look like this:

Hint: the team query added there will be parsed by WordPress and made available in the controller; you can then choose to either ignore it or filter the results by it – anything you want!

The easiest way to test your endpoints, especially if they will require an application password to access, is to use a tool like Postman which lets you test APIs in a very user-friendly manner. Publicly available GET requests can also be tested by simply visiting the URL endpoint in your browser!

Querying via GraphQL

Now that we are able to fetch the data via REST routes, let’s explore how we might be able to fetch it using GraphQL as well.

If you’re unfamiliar with GraphQL, what you need to know is that it’s actually a querying language just like SQL but for APIs. You can read more about it on the official website over at https://graphql.org/.

The simplest way to add GraphQL support to our site is by installing the newly-canonical plugin WPGraphQL. It also has a documentation page where you can learn more about what it provides out-of-the-box, and also examples of how to handle much more complex scenarios.

If you’ve been paying attention to the JSON configuration of the custom post types shared above, you might’ve already noticed a key named show_in_graphql set to 1 (true/active). That is all we need in order to allow the custom post types we added to be queries using GraphQL.

Here is an example of a GraphQL query that can be used to list Employees which you can test in the built-in GraphiQL IDE bundled with the plugin:

Building your own

If this sounds like something you want to build for your own business, you can work on it on your own computer using Studio by WordPress.com. You can even share your work with colleagues (for free!) using a demo site, and when you’re ready, any WordPress.com Business plan or higher will be able to host and manage your site.