REST API

When to use it

Build, debug or review WordPress REST routes, argument schemas, authentication, object permissions, responses and pagination. Use for 401/403/400 responses, nonce or Application Password problems, missing permission_callback, collections and caching; not admin screens.

Boundaries and hand-offs

Plugin bootstrap, hooks and storage go to wp-devkit-plugin-development; the admin screens that call the API go to wp-devkit-admin-ui-development; WPGraphQL and decoupled front ends go to wp-devkit-headless-and-wpgraphql; broad exploit analysis goes to wp-devkit-security-review. This skill owns the request boundary: routes, auth, validation, response and cache behavior.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:rest-review <target-path>

The short form /wp-devkit:rest requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-rest-api-development
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• authentication-and-permissions.md : read for cookie nonces, Application Passwords, 401 vs 403, object checks, public routes, CORS, abuse controls.
• responses-collections-and-caching.md : read for errors and statuses, pagination, _fields / _embed , caching and CDN, idempotency, retries.
• rest-api-development-workbook.md : REST contracts and request boundaries workbook
• route-registration-and-schema.md : read for registration rules, controllers, how core validates args, schema keywords and coercion, fields/meta, versioning.

How a review runs

1. Find registration ( register_rest_route , controller register_routes , register_rest_field , register_meta with show_in_rest ) and trace in dispatch order: authentication, route match, required/ validate_callback checks, sanitization, permission_callback , handler, response conversion (confirmed in WP_REST_Server::dispatch() and respond_to_request() ).
2. Write the expected method, object scope, inputs, response shape and error behavior from the existing contract. Do not add a new endpoint to bypass a failing one.
3. Check object-level authorization for reads and writes, including every identifier in the payload. Intentional public submissions can be valid; assess data exposure, side effects and abuse controls rather than demanding authentication.
4. Check validation at the real boundary: a custom sanitize_callback replaces implicit schema validation; parameters resolve body-first; confirm the permission callback and handler read the same identifier.
5. Check responses: whitelisted fields, correct context , WP_Error with status , pagination bounds and headers, and cache headers for private data.
6. Describe anonymous, authorized, wrong-owner and malformed-input checks. Do not issue mutating requests during review.
7. Classify per the contract; keep pattern hits as candidates; use insufficient evidence when the auth model, version or CDN rules are unknown. Read references/rest-api-development-workbook.md for symptom triage, worked decisions, benign look-alikes and verification recipes. Load topic references only when in scope: - references/route-registration-and-schema.md : read for registration rules, controllers, how core validates args, schema keywords and coercion, fields/meta, versioning. - references/authentication-and-permissions.md : read for cookie nonces, Application Passwords, 401 vs 403, object checks, public routes, CORS, abuse controls. - references/responses-collections-and-caching.md : read for errors and statuses, pagination, _fields / _embed , caching and CDN, idempotency, retries.

What you get back

Review: result and reviewed scope first. Each confirmed finding: file:line, actor, trigger, reachable path, impact, confidence, severity (per contract), minimal fix, regression. Candidates and missing evidence separate. Implementation: contract, changed boundaries, commands with exit status, unexecuted checks, residual risk.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.