Why it shows up in your week
A headless launch is two weeks out. The React app expects custom fields that never appear in REST responses. Or worse, application passwords were created for a demo and never revoked. The API is where content architecture meets security.
In plain language
Public sites often allow read access to published content. Create, update, and delete need authenticated users with the right capabilities.
Custom post types and fields need explicit REST support. ACF and similar tools must be configured before a headless frontend can rely on them.
Application passwords, OAuth plugins, and JWT setups are credentials. Treat them like production API keys with rotation and least privilege.
Headless WordPress uses the REST API (or GraphQL plugins) as the content backend while another front end renders HTML.
Disable or lock down routes you do not need. Every open write endpoint is an attack surface.
Facts worth keeping
- Base path
- Typically /wp-json/
- Format
- JSON over HTTP
- Shipped in core
- REST API matured into WordPress core (4.7+ era for core content routes)
- Common clients
- Headless frontends, mobile apps, Zapier-class automations, custom integrations
- Auth options
- Cookie auth (admin), application passwords, OAuth/JWT via plugins
Not the same as
- WP-CronA job scheduler, not an HTTP content API.
- GraphQL for WordPressA separate plugin approach some headless stacks prefer. Different query model, same need for auth and field exposure discipline.
- The admin-ajax.php habitOlder WordPress patterns posted to admin-ajax. REST is the clearer contract for modern integrations.
Where it bites
The REST API hurts when a headless launch discovers missing fields, or when application passwords and plugin routes stay open wider than the security review assumed.
Content freezes and credential cleanups then land in the same week as a marketing deadline.
What to check
- Which endpoints are public, and which require authentication?
- Do custom fields required by the frontend appear in REST responses on purpose?
- Are application passwords and plugin routes reviewed like any other production API?
- Is there rate limiting or WAF rules for /wp-json/ abuse?
- Who owns the contract when the frontend team needs a new field?
Common questions
What is the WordPress REST API?
The built-in JSON HTTP API for reading and writing WordPress data, typically under /wp-json/.
Do you need the REST API for a normal WordPress site?
Many classic sites barely use it. Headless frontends, mobile apps, and automation workflows depend on it.
Is exposing /wp-json/ dangerous?
Read access to public content is normal. Write routes and verbose user endpoints need hardening, auth, and monitoring.
What should you check first?
Map public versus authenticated routes, confirm custom fields are exposed on purpose, and review credentials the same way you would for any production API.
REST or headless CMS instead?
If WordPress editorial workflow is a strength, REST/headless WordPress can work. If the CMS model fights your product, evaluate purpose-built headless CMS options.