A REST API is a way for other software to read and change a website’s data using ordinary web addresses and standard requests, rather than by loading pages. A tool sends a request to a set address, called an endpoint, and gets back structured data, usually as JSON, that it can use or display however it needs.
How a REST API works
REST is a set of conventions for designing an API. Each type of data has its own address, and the kind of request says what you want to do with it: GET to read, POST to create, PUT or PATCH to update and DELETE to remove. Responses come back with a status code, such as 200 for success or 401 for not authorised, alongside the data.
WordPress has had a built-in REST API since version 4.7. Its endpoints live under /wp-json/ on your domain. Visiting yourdomain.co.uk/wp-json/wp/v2/posts in a browser returns your published posts as JSON. Public content can be read by anyone; creating, editing or deleting anything requires authentication, typically through Application Passwords, which WordPress added in version 5.6, or a plugin that issues tokens.
Much of WordPress depends on it. The block editor saves your work through the REST API, many form, booking and SEO plugins use it, and a headless front end fetches all its content this way.
Why it matters
The REST API is how your website talks to other tools. A CRM that creates blog drafts, an automation service that adds each new enquiry to a spreadsheet, a stock system that updates WooCommerce product prices, or a mobile app that shows your latest articles all rely on it, directly or through connectors such as Zapier and Make. For a small UK business, that can replace a lot of copying and pasting.
It also affects security. By default, WordPress lists users who have published posts at /wp-json/wp/v2/users, with a slug that often matches the login name, which gives attackers half of what they need for password-guessing. Plugins sometimes add endpoints that expose more data than intended, such as order details or form entries, and those have been the source of real vulnerabilities.
For SEO, the /wp-json/ addresses are rarely a problem. Google can find them, but they return JSON rather than pages, so they are not normally indexed. What matters more is that blocking the API with an overzealous security plugin can break forms, the editor and parts of the front end that search engines need to render.
Common mistakes
- Disabling the REST API entirely for security, which breaks the block editor, contact forms and some page features.
- Connecting a third-party tool with a full administrator account rather than a limited user and an Application Password.
- Leaving the user listing endpoint open with usernames that match login names.
- Not revoking Application Passwords when a contractor or integration is no longer used.
- Blocking /wp-json/ in robots.txt, which can stop Google rendering pages that load content through it.
How to act on it
Visit /wp-json/ on your own site to see what is public, and check /wp-json/wp/v2/users in particular. If it shows names you would rather keep private, restrict that endpoint with a security plugin or a small code change rather than switching the whole API off. Under Users, review which Application Passwords exist and revoke any you do not recognise.
When you add an integration, give it its own user with the lowest role that works, and note what it can change. Checking endpoints, integrations and what search engines can render on a WordPress site is part of my WordPress SEO service.