What the API Lets You Do
Last updated:
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.
Frequently asked questions
Is the API on by default?
Does headless improve speed?
Can it write as well as read?
What about plugins in a headless setup?
Maintaining the same content in two places?
The API means writing it once. Tell us what the second destination is.