- Article
- 3 minutes read
- Reviewed August 3, 2026
The WordPress REST API exposes content through JSON endpoints. It allows the block editor, JavaScript interfaces and external applications to read and modify WordPress data according to authentication and permissions.
Custom post types, taxonomies and metadata can use the standard REST infrastructure when they are registered correctly.
REST Endpoints as Resources
The API represents posts, pages, media, terms, users and other objects as resources. Clients use HTTP methods to retrieve collections, read one item, create, update or delete records.
The default API base is normally available below /wp-json/wp/v2/.
Exposing a Custom Post Type
Set show_in_rest to true when registering the post type. WordPress can then use its standard posts controller and create routes in the wp/v2 namespace.
The registration can customize the REST base or controller, but changing defaults should serve a clear compatibility requirement.
Exposing a Custom Taxonomy
A taxonomy also needs show_in_rest enabled to provide standard taxonomy and term routes and modern editor integration.
Associated post type responses can include term references depending on the registered schema.
Exposing Metadata
Register metadata with its type, single or multiple behaviour, authorization, sanitization and show_in_rest configuration.
The post type generally needs custom-fields support for registered post metadata to appear and update through standard REST behaviour.
Schemas and Validation
REST schemas describe expected properties and types. Clear schemas help clients validate input and understand responses.
Do not expose mixed-format metadata and expect every client to infer its meaning.
Authentication
Public GET requests may read public content without authentication. Creating or modifying content requires an authenticated user or application with the necessary capabilities.
Application Passwords are one core option for external HTTPS clients. Browser-based WordPress requests commonly use cookie authentication and nonces.
Authorization
Authentication identifies the requester. Authorization determines whether that identity can perform the action.
Custom endpoints must define a real permission callback and check capabilities or object-level rules.
Private and Internal Content
Exposing a post type in REST does not mean every record should be public. Standard controllers filter content according to status and permissions.
Custom controllers and query parameters must preserve those rules and avoid leaking restricted fields.
Custom Fields and Sensitive Data
Do not expose internal notes, secrets or personal data merely because they are stored as metadata. Register only fields intended for the API and use authorization callbacks where access differs.
Performance and Pagination
Collection endpoints use pagination and limits. Applications should request only required fields, cache appropriately and avoid downloading entire large collections repeatedly.
Complex filters may require custom endpoints or indexed storage rather than unbounded metadata queries.
Versioning and Compatibility
An external consumer treats field names, types and endpoint paths as a contract. Changing them can break applications even when the WordPress website still renders correctly.
Document changes, preserve compatibility or create a versioned endpoint when a breaking redesign is necessary.
REST Readiness Checklist
- Enable REST only for content intended to participate.
- Register metadata with stable types and schemas.
- Apply authentication and object-level authorization.
- Exclude sensitive fields.
- Test public, authenticated and unauthorized responses.
- Use pagination and efficient filters.
- Document the API contract and breaking-change policy.
Frequently Asked Questions
Does show_in_rest make all custom post type content public?
No. It registers REST routes, while individual responses still depend on public status, query settings and permissions.
Why is registered post meta missing from REST responses?
Check that the metadata has show_in_rest enabled and that the post type supports custom fields.
Can I create custom REST endpoints?
Yes. Use them when standard controllers do not represent the required resource, and always provide appropriate schema and permission callbacks.