What it exposes
Posts, pages, custom post types, media, taxonomies, users and comments, with full read and write where you permit it.
That makes WordPress usable as a content backend for things that are not a WordPress front end.
Four practical uses
- Headless front end — content in WordPress, presentation in a modern framework
- Mobile app content — one source, several destinations
- Syndication — publish once, distribute to partner sites
- Integration — other systems reading or writing content
The second is underrated. A business with a website and an app usually maintains content twice; the API means writing it once.
Headless is not automatically better
| Gain | Cost |
|---|---|
| Front-end flexibility | Two systems to maintain |
| Potentially faster pages | Preview and editing get harder |
| Reuse across channels | Plugins that output HTML stop working |
| Modern developer experience | Higher build and hosting cost |
Worth it when you genuinely need several front ends or a very specific interface. Not worth it for a brochure site.
Secure it deliberately
- Authentication for anything beyond public content
- Disable endpoints you do not use
- Rate limit, because an open API is an open API
- Never expose user enumeration or draft content publicly
Custom endpoints
You can add your own endpoints for business-specific operations rather than forcing everything through the standard content routes.
That is usually cleaner and it keeps your business logic on the server where it belongs.