1. What is the WordPress REST API?
The WordPress REST API is a built-in feature of WordPress — available in every installation since version 4.7 (released in 2016) — that provides a standardised way for external applications to interact with your WordPress site. REST stands for Representational State Transfer, which is an architectural style for building web services. API stands for Application Programming Interface, which is essentially a set of rules for how two pieces of software talk to each other.
In practical terms: the WordPress REST API is a door in the back of your WordPress site. Through that door, any authorised application can read your posts and pages, create new content, update existing content, or delete records — all without needing to log in to the WordPress admin dashboard. Requests go in as standard HTTP calls (GET to read, POST to create, PUT to update, DELETE to remove) and responses come back as JSON — a lightweight, universally readable data format.
For UK business owners, the key insight is this: the REST API is what makes WordPress capable of behaving as more than a website. It is what allows WordPress to serve as a content backend for a mobile app, a data source for a custom React front-end, or an integration point for your CRM — all without giving those systems direct database access.
What the REST API exposes by default
- Posts, pages, and custom post types — readable and writable
- Categories, tags, and custom taxonomies
- Media library items (images, files)
- Comments
- Users (username enumeration is a common security consideration)
- Site settings (title, description, timezone)
- Block types (used by the Gutenberg editor itself)
2. How the REST API actually works (plain English)
Every WordPress site with the REST API enabled has a base URL that looks like this:https://yoursite.co.uk/wp-json/wp/v2/— this is called the root endpoint. Appending different path segments to that root lets you access different types of content.
| Endpoint | What it returns | Typical use |
|---|---|---|
| /wp-json/wp/v2/posts | All published posts as JSON | Headless blog, mobile app |
| /wp-json/wp/v2/pages | All published pages | Headless page content |
| /wp-json/wp/v2/posts/123 | Single post by ID | Single article page |
| /wp-json/wp/v2/categories | All categories | Navigation, filtering |
| /wp-json/wp/v2/media | Media library items | Image galleries, assets |
| /wp-json/wp/v2/users | Author list | Author profiles (restrict in production) |
Requests can also include query parameters to filter results — for example,?categories=5&per_page=10returns the ten most recent posts in category 5. This is how a headless front-end builds category archive pages or pagination without ever loading a WordPress PHP template.
For write operations — creating a post, submitting a form response, uploading an image — the request must include authentication credentials. WordPress supports several authentication methods: cookie-based (for same-origin requests), application passwords (the recommended method for third-party integrations), and JWT (JSON Web Tokens, via a plugin) for stateless authentication in mobile apps or SPAs.
3. When UK businesses actually need the REST API
Most standard WordPress business websites — a marketing site, a WooCommerce store, a professional services blog — do not require any direct REST API work from the site owner. WordPress uses the REST API internally (the Gutenberg block editor runs on it), and plugins like WooCommerce and Yoast use it without requiring any configuration.
The REST API becomes a deliberate architectural decision in the following scenarios:
Building a mobile app that displays WordPress content
£3,000–£8,000A membership site, events company, or publication that wants a native iOS or Android app can use the WordPress REST API to feed content from the existing WordPress back-end into the app. The editorial team manages everything in WordPress; the app reads posts, pages, and custom fields via REST.
Development effort: Medium
Headless WordPress with a Next.js or React front-end
£8,000–£30,000The most common advanced use case in 2026. WordPress handles content management; Next.js handles rendering. The front-end fetches content at build time (SSG) or request time (SSR) via the REST API. This gives editorial teams the familiar WordPress interface while delivering the performance and developer experience of a modern JS framework.
Development effort: High
CRM integration — pushing leads from WordPress to Salesforce or HubSpot
£800–£3,000A form submission on a WordPress contact page fires a webhook or custom REST API call to a CRM. The lead is created in Salesforce or HubSpot in real time without manual import. Bi-directional sync (e.g., updating WordPress with CRM data) requires a more complex custom integration.
Development effort: Low to medium
Custom dashboards or internal tools reading WordPress data
£2,000–£8,000A management team wants a custom analytics dashboard that pulls data from their WordPress membership site — user registrations, subscription status, post engagement — and displays it alongside data from other systems. The REST API is the data source.
Development effort: Medium
Multi-platform content syndication
£0 (Zapier) to £1,500 (custom)A publisher wants new posts automatically pushed to a separate site, an email marketing tool, a Slack channel, or a social scheduling tool when published in WordPress. Zapier, Make (Integromat), and n8n can all consume the WordPress REST API as a trigger source — no custom code required for basic workflows.
Development effort: Low
4. Headless WordPress: REST API vs WPGraphQL
"Headless" WordPress means decoupling the WordPress content management layer from the presentation layer. WordPress becomes a pure back-end — storing and serving content — while a separate front-end application (typically built in Next.js, Nuxt, or Astro) handles rendering. The two communicate via an API: either the built-in REST API or the WPGraphQL plugin.
Both approaches work. The choice depends on the complexity of your content model and the preferences of your development team.
| REST API | WPGraphQL | |
|---|---|---|
| Built into WordPress core | Yes | No — plugin required |
| Data fetching | Fixed JSON structure per endpoint | Query exactly the fields you need |
| Over-fetching | Common — full objects returned | Minimal — request only what you need |
| Learning curve | Low — standard HTTP | Medium — GraphQL query syntax |
| Custom post type support | Yes (show_in_rest: true) | Yes (show_in_graphql: true) |
| ACF field support | Via plugin or register_rest_field | Via WPGraphQL for ACF plugin |
| Best for | Simpler builds, quick integrations | Complex data models, large headless apps |
| UK agency day rates | £400–£700/day | £500–£800/day |
For most UK businesses starting their first headless WordPress project, the REST API is the lower-risk choice: no extra plugin dependency, well-documented, and supported by a larger pool of UK developers. If your content model involves deeply nested relationships between many custom post types — for example, a property portal with listings, agents, developments, and locations all linked — WPGraphQL is worth the additional setup cost.
WebAnts builds headless WordPress front-ends using both approaches. Book a free discovery call and we will recommend the right architecture for your content model and budget.
5. CRM and third-party integrations via the REST API
For many UK professional services firms, the most valuable use of the WordPress REST API is not a headless front-end — it is connecting WordPress to their CRM. A contact form that automatically creates a lead in Salesforce or HubSpot eliminates the manual import step that most agencies and consultancies currently perform, and ensures that enquiries are followed up within minutes rather than hours.
There are two main approaches to WordPress-CRM integration, each with different cost and complexity implications:
Plugin-based integration (low code)
£0–£500Plugins like WPForms, Gravity Forms, and Ninja Forms have built-in integrations with HubSpot, Salesforce, ActiveCampaign, Mailchimp, and dozens of other platforms. Setup is configuration rather than code — select the CRM, map form fields to CRM fields, and test. This covers the majority of one-way (WordPress to CRM) lead capture scenarios.
Good for: Simple one-way lead sync, standard CRM platforms
Not ideal for: Complex field mapping, bi-directional sync, custom CRM instances
Webhook-based integration (medium code)
£200–£1,000 setup + automation tool subscriptionWordPress fires a webhook on form submission; the webhook is consumed by a no-code automation tool (Zapier, Make, n8n) which maps data and creates the CRM record. More flexible than plugins — works with almost any CRM — but introduces an additional dependency and monthly cost.
Good for: Non-standard CRMs, moderate data transformation needs
Not ideal for: High-volume forms, real-time sync requirements, complex bi-directional logic
Custom REST API integration (full code)
£1,500–£5,000A custom WordPress plugin or mu-plugin that fires REST API calls directly to the CRM's API on defined events (form submission, post publication, user registration). No third-party automation tool in the chain. Handles bi-directional sync, complex field mapping, error handling, and logging.
Good for: Bi-directional sync, complex data models, high reliability requirements
Not ideal for: Simple one-way lead capture — overkill for basic scenarios
6. WordPress REST API security: what UK businesses must know
The WordPress REST API is enabled by default on every WordPress installation and is publicly accessible without authentication for read operations on public content. This is intentional — it is what allows Google to crawl your site and what allows RSS readers and aggregators to consume your content. But it also exposes information that some businesses would prefer to restrict, and opens attack vectors if not properly configured.
Here are the security considerations every UK business should discuss with their WordPress developer before any API work goes live:
User enumeration via /wp-json/wp/v2/users
Risk: HighBy default, the /users endpoint returns a list of registered usernames and user IDs. This gives attackers a valid username to target in brute-force login attempts. If your site has multiple registered users, this endpoint should be restricted to authenticated requests.
Fix: Add a REST API filter in functions.php to require authentication for the /users endpoint, or disable it entirely if you do not need it publicly accessible.
Exposing private post content
Risk: MediumThe REST API respects WordPress post visibility by default — private and password-protected posts are not returned without authentication. But custom post types and third-party plugins may not implement visibility correctly. Test every custom CPT endpoint before going live.
Fix: Audit all custom CPT endpoints. Set permission_callback to require authentication for any endpoint that might return sensitive content.
Authentication method selection
Risk: MediumWordPress application passwords (introduced in WordPress 5.6) are the recommended authentication method for server-to-server integrations. Avoid storing admin credentials in third-party tools or environment variables where they may be exposed. JWT tokens (via a plugin) are appropriate for mobile app authentication.
Fix: Use application passwords for server-to-server; JWT for mobile/SPA. Rotate credentials regularly and revoke application passwords for integrations that are no longer active.
Rate limiting and abuse prevention
Risk: Low to mediumWordPress does not include built-in rate limiting for REST API requests. A publicly accessible REST API endpoint that performs expensive database queries can be abused to cause a denial-of-service condition on shared hosting.
Fix: Implement rate limiting at the server or CDN level (Cloudflare, Nginx). Cache REST API responses where possible using the Transients API or an object cache.
If you have an existing WordPress site and are not sure whether your REST API is properly secured, visit yoursite.co.uk/wp-json/wp/v2/users in a browser. If you see a list of your registered usernames without being logged in, that endpoint needs to be restricted. WebAnts includes REST API security configuration as standard in all WordPress builds.
7. REST API development cost in the UK
The cost of WordPress REST API work varies significantly based on what you are building. The table below gives realistic ranges for UK agencies doing custom-code work — not offshore development quoted in pounds.
| Project type | Typical cost (GBP) | Timeline |
|---|---|---|
| Restricting/securing existing REST API | £300–£600 | 1–2 days |
| Single custom REST endpoint (read-only) | £500–£1,000 | 2–4 days |
| Single custom endpoint with authentication and write operations | £800–£1,500 | 3–5 days |
| WordPress-to-CRM integration (plugin-based) | £300–£600 | 1–2 days |
| WordPress-to-CRM integration (custom code, one-way) | £1,000–£2,500 | 3–7 days |
| Bi-directional CRM sync | £2,500–£5,000 | 1–2 weeks |
| Headless WordPress (REST API + Next.js front-end) | £8,000–£20,000 | 4–10 weeks |
| Headless WordPress (WPGraphQL + Next.js) | £12,000–£30,000 | 6–14 weeks |
These are budgetary figures for scoping purposes. WebAnts provides flat written quotes after a free 30-minute discovery call — not hourly estimates. No prepayment is required on any project.
8. Questions to ask before hiring a WordPress API developer
REST API work is an area where scope can expand quickly if not properly defined upfront. These are the questions to ask any agency or developer before work begins:
"Will you secure the API as part of this project?"
Any developer adding REST API functionality should also review and configure security settings — restricting the /users endpoint, setting up proper authentication, and testing for data exposure. If they do not mention security, ask explicitly.
"How will authentication be handled?"
Application passwords for server-to-server; JWT for mobile/SPA. Ask which method they are recommending and why. "We will use the admin password" is a red flag.
"How will errors be handled and logged?"
A REST API call that fails silently — a CRM integration that stops syncing, a headless front-end that returns stale data — can go unnoticed for days. Ask about error handling, logging, and alerting.
"What happens to the integration when WordPress or a plugin is updated?"
WordPress major versions occasionally introduce REST API changes. Custom integrations built against a specific WooCommerce version may break on upgrade. Ask whether the integration is tested against the WordPress upgrade cycle.
"Will you document the custom endpoints?"
Any custom endpoint your developer builds should be documented — the URL, the parameters it accepts, the response format, and the authentication method. This is essential if another developer ever needs to maintain or extend the integration.
"How will performance be managed?"
Headless front-ends that hit the REST API on every page request can be slow without caching. Ask about their caching strategy — transients, object cache, or static generation at build time.
9. Frequently asked questions
What is the WordPress REST API?
The WordPress REST API is a built-in interface (available since WordPress 4.7) that lets external applications read and write WordPress data — posts, pages, custom post types, users — using standard HTTP requests that return JSON. It is the door in the back of your WordPress site that lets other software talk to it.
Do I need the REST API for a standard business website?
No. A standard marketing site, WooCommerce store, or blog does not require direct REST API work. The REST API is used behind the scenes by WordPress itself and by most plugins. You need to think about it actively only when building a mobile app, a headless front-end, or a CRM integration.
Is the WordPress REST API secure by default?
It is functional by default, but best practice requires additional configuration: restricting sensitive endpoints to authenticated users, disabling user enumeration via /users, and using application passwords or JWT tokens for integrations. A reputable agency should configure these as standard.
What is the difference between the REST API and WPGraphQL?
The REST API is built into WordPress core and returns fixed JSON structures. WPGraphQL is a plugin that lets you query exactly the fields you need — reducing over-fetching. For simple integrations, REST is sufficient. For large headless applications with complex data requirements, WPGraphQL is typically better architecture.
How much does REST API development cost in the UK?
A single custom endpoint typically costs £500–£1,500. A full headless WordPress build (Next.js front-end consuming WordPress content via REST API) costs £8,000–£30,000. Ongoing CRM integration work is scoped per project. WebAnts provides flat quotes after a free 30-minute discovery call.
Can the REST API connect WordPress to Salesforce or HubSpot?
Yes. Form submissions can trigger webhooks or REST API calls to a CRM on submission. Off-the-shelf plugins handle basic integrations; custom development is needed for complex data mapping or bi-directional sync.
Does the REST API work with custom post types?
Yes. Any CPT registered with show_in_rest: true gets its own REST endpoint. ACF fields can be exposed using the ACF to REST API plugin or by registering fields manually via register_rest_field.
Does WebAnts build WordPress REST API integrations?
Yes. WebAnts is a London WordPress development agency building custom REST API endpoints, headless WordPress builds, and third-party integrations. All work is custom-coded, flat-quoted, and requires no prepayment.