wp-rest-api
by WordPressThe wp-rest-api skill helps you build, extend, and debug WordPress REST endpoints with less guesswork. Use it for route registration, permission_callback and auth checks, schema and argument validation, response shaping, register_rest_field/register_meta, and exposing CPTs or taxonomies via show_in_rest. It is a practical wp-rest-api guide for API Development in plugins, themes, and mu-plugins.
This skill scores 84/100, which means it is a solid listing candidate for directory users who want WordPress REST API implementation guidance with meaningful leverage over a generic prompt. The repository gives clear trigger conditions, concrete workflow steps, and focused references for routes, auth, schema, discovery, and fields, so an agent can usually act with less guesswork.
- Explicit trigger scope covers route creation, debugging 401/403/404 issues, custom fields/meta, CPT/taxonomy exposure, and schema validation.
- Operational workflow is concrete: triage first, search existing REST usage, then choose an approach with specific WordPress APIs and constraints.
- Reference files provide quick lookup for the main REST concerns: authentication, endpoints, schema, discovery, and response shaping.
- No install command or scripts are provided, so users must integrate the skill manually into an agent workflow.
- Some guidance is summary-level rather than end-to-end, so complex implementations may still require WordPress-specific judgment beyond the skill text.
Overview of wp-rest-api skill
What wp-rest-api is for
The wp-rest-api skill helps you work on WordPress REST endpoints with less guesswork: creating routes, exposing content types, validating parameters, shaping responses, and fixing auth or permission failures. It is most useful when you need a practical wp-rest-api guide for API Development inside a real plugin, theme, or mu-plugin—not just a generic prompt.
Who should use it
Use the wp-rest-api skill if you are adding or debugging register_rest_route(), WP_REST_Controller, register_rest_field, register_meta, show_in_rest, or REST schema/validation logic. It is a strong fit for developers who need a fast install decision on whether the repo supports their endpoint work and how to approach it safely.
What makes it different
This skill is centered on WordPress-specific constraints that often block adoption: permission_callback, nonce or application password auth, route namespacing, context=edit, _fields, and schema-driven validation. The main value of wp-rest-api is that it points you toward the right REST pattern before you start coding, which reduces broken permissions, client regressions, and invalid response shapes.
How to Use wp-rest-api skill
Install and confirm scope
Install the wp-rest-api skill with npx skills add WordPress/agent-skills --skill wp-rest-api. Before editing, confirm you are in the correct repo root and identify the exact plugin/theme entrypoint. If the project is a full site codebase, narrow to the single component that owns the endpoint.
Gather the minimum inputs
For best wp-rest-api install results, provide: target namespace and version, route path, intended HTTP method, auth mode, and WordPress version floor. A weak request is “add an endpoint.” A stronger request is: “add my-plugin/v1/orders for authenticated editors, return only order ID, status, and total, validate page and per_page, and support ?_fields= for client performance.”
Read the right files first
Start with SKILL.md, then inspect references/routes-and-endpoints.md, references/authentication.md, references/schema.md, references/responses-and-fields.md, references/discovery-and-params.md, and references/custom-content-types.md. Those files tell you how the skill expects routes, permissions, schema, and content exposure to be wired, which is more useful than skimming the repo blindly.
Follow the practical workflow
Use the skill to triage existing REST usage, then choose the implementation path: custom route, controller class, or exposing an existing type. Build the prompt around the intended resource shape, not just the endpoint name. For example, include whether the response should be public or edit-only, whether it should reuse core fields, and whether the data comes from post meta, a CPT, or computed logic. That gives the model enough context to produce a usable wp-rest-api usage result.
wp-rest-api skill FAQ
Is this only for custom routes?
No. The wp-rest-api skill also fits exposing CPTs and taxonomies through show_in_rest, adding custom fields or meta, and adjusting response behavior for existing endpoints. If you only need a one-off fetch example, a plain prompt may be enough; if you need route design or compatibility checks, the skill is a better fit.
When should I not use wp-rest-api?
Skip it if your task is unrelated to WordPress REST internals, or if you are working in a client app that only consumes an already-stable API. It is also a poor fit when the server code cannot be changed and you only need documentation or request examples.
Is it beginner-friendly?
Yes, if you are comfortable editing WordPress PHP files and can describe the desired resource clearly. The main beginner risk is under-specifying auth and permissions, which leads to routes that appear to work but fail for logged-out users, editors, or external clients.
How does it compare with a generic prompt?
A generic prompt may suggest code, but wp-rest-api is more useful when you need WordPress-specific guardrails: required permission_callback, schema validation, response shaping, and route discovery. That makes the skill better for install decisions when you care about reliability, not just syntax.
How to Improve wp-rest-api skill
Give the model the resource shape, not just the goal
The highest-value improvement is to specify what the endpoint should return and who may call it. State the object type, fields, write access, and any special filters. Example: “return published products with id, name, price, and stock_status; allow authenticated managers to update stock_status only.” This makes the wp-rest-api skill far more precise.
Provide failure context up front
If you are debugging, include the exact symptom: 401 vs 403 vs 404, missing nonce, bad namespace, or invalid schema. Mention whether the route is public, cookie-authenticated, or uses application passwords. That helps the model distinguish auth failure from route registration or data-shape problems.
Use repository details in your prompt
Name the relevant files, controller classes, or post types already present in the repo. If the code already has show_in_rest, rest_base, or meta registration, say so. The best wp-rest-api guide outputs usually come from prompts that anchor on the existing architecture instead of asking for a fresh implementation from scratch.
Iterate from validation to polish
After the first output, ask for one narrow improvement at a time: stricter schema, better permission checks, response trimming with _fields, or route compatibility with non-pretty permalinks. If output quality is still off, tighten the prompt by adding the exact request and expected JSON shape; that is usually more effective than asking for a “better” endpoint.