Originally published: August 18, 2021 · Last updated: August 17, 2026
The WordPress REST API already exposes a substantial part of WordPress through JSON endpoints. Before installing a plugin that promises to “expand the API”, check whether the data and operations you need are already available in core.
The REST API powers important WordPress interfaces, including the block editor, and can also connect WordPress with external applications, dashboards and automation tools.
Start with the core endpoint inventory
WordPress provides standard routes for posts, pages, media, users, comments, categories, tags, post types, revisions and other resources. Explore the API index and reference before creating a custom route.
For public content, many read operations are available without authentication. Protected content and write operations follow WordPress permissions and authentication rules.
Expose custom post types deliberately
If a custom post type should use the normal WordPress REST controllers, register it with REST support. WordPress can then create endpoints in the standard wp/v2 namespace.
The same principle applies to custom taxonomies. Reusing core controllers is generally simpler and more compatible than inventing a parallel API for content that behaves like ordinary WordPress content.
Create custom endpoints for real application logic
A custom route makes sense when the operation is not simply CRUD on an existing WordPress object. Examples include a specialized report, an action involving several data sources or an integration-specific workflow.
Custom routes should define their methods, permissions, arguments and response schema clearly. Do not expose internal operations publicly just because building an endpoint is convenient.
Use proper authentication
Same-site WordPress applications commonly use cookie authentication with REST nonces. For external applications, WordPress Application Passwords provide revocable credentials tied to a user account and are preferred over sharing the user’s main password.
Give integrations only the WordPress user permissions they actually need, and revoke credentials that are no longer used.
Do not use a plugin merely to expose everything
Some older REST API tutorials recommend plugins that turn arbitrary custom fields or database data into public endpoints. That can be convenient, but it can also expose information unintentionally and make the data contract dependent on another plugin.
First ask whether the content should be public, whether it already has registered REST support and whether a narrow custom endpoint would be safer.
Think about the API as a contract
External consumers may depend on field names, routes and response structures for years. Changing an API casually can break mobile apps, integrations and automation.
Document custom routes and keep the returned data stable. If a breaking change is necessary, version the custom namespace rather than silently changing existing behavior.
Performance still matters
A REST endpoint can become expensive if it performs large database queries or returns huge payloads for every request. Use pagination, filters and appropriate permissions. Return the data the client needs instead of exposing an entire internal object graph.
A practical decision sequence
- Check whether a core endpoint already solves the problem.
- Enable REST support on custom content types when appropriate.
- Use a custom route only for distinct application logic.
- Define permissions before implementation.
- Use WordPress authentication mechanisms.
- Document and version integrations that other systems depend on.
The practical rule
Extend the WordPress REST API from the smallest useful surface. Core already covers most content-management tasks. Add custom endpoints when your application genuinely needs new behavior, not because exposing more database data feels flexible.
Official references: WordPress REST API Handbook, REST API endpoint reference, REST support for custom content types and Application Passwords.