agentleFS
wpgauravwpgaurav/WordPress-skills/skills/wordpress/wp-rest-api/SKILL.md

wp-rest-api

Skill19 starsChanged 20 days agoMITView on GitHub

Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest.

7 other projects use a version of this, 5 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. 8 are common, 0 are distinctive, and 13 are very specific to this project.

  • 8

    Common

    Most of the 6 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 13

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Use this skill when you need to:

    line 14
  2. Common:

    create or update REST routes/endpoints

    line 16
  3. Common:

    add custom fields/meta to REST responses

    line 18
  4. Common:

    Search for existing REST usage:

    line 36
  5. Common:

    If this is a full site repo, pick the specific plugin/theme before changing code.

    line 42
  6. Very specific:

    Use show_in_rest => true + rest_base if needed.

    line 47
  7. Very specific:

    Use register_rest_route() on rest_api_init.

    line 51
  8. Very specific:

    Prefer a controller class (WP_REST_Controller subclass) for anything non-trivial.

    line 52
  9. Very specific:

    Read references/routes-and-endpoints.md and references/schema.md.

    line 53
  10. Very specific:

    Use a unique namespace vendor/v1.

    line 57
  11. Very specific:

    Always provide permission_callback (use __return_true for public endpoints).

    line 58
  12. Very specific:

    Prefer JSON Schema validation with rest_validate_value_from_schema then rest_sanitize_value_from_schema.

    line 68
  13. Very specific:

    Never read $_GET/$_POST directly inside endpoints.

    line 69
  14. Common:

    Do not remove core fields from default endpoints.

    line 75
  15. Very specific:

    Use register_rest_field for computed fields.

    line 76
  16. Very specific:

    If you need unfiltered post content (e.g., ToC plugins injecting HTML), request ?context=edit to access content.raw (auth required).

    line 78
  17. Very specific:

    Add related resource links via WP_REST_Response::add_link().

    line 79
  18. Very specific:

    Use capability checks in permission_callback (authorization), not just “logged in”.

    line 87
  19. Very specific:

    Ensure discovery works (Link header or <link rel="https://api.w.org/">).

    line 93
  20. Common:

    Run repo lint/tests and any PHP/JS build steps.

    line 105
  21. Common:

    If version support or behavior is unclear, consult the REST API Handbook and core docs before inventing patterns.

    line 117

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

From Agent Skills for WordPress. Copyright (C) 2026 WordPress Contributors, licensed under GPL-2.0-or-later. Changed from upstream: the compatibility: frontmatter line was dropped when this copy was made in March 2026, and license frontmatter plus this notice were added on 2026-10-24. See NOTICE.md.

WP REST API

When to use

Use this skill when you need to:

  • create or update REST routes/endpoints
  • debug 401/403/404 errors or permission/nonce issues
  • add custom fields/meta to REST responses
  • expose custom post types or taxonomies via REST
  • implement schema + argument validation
  • adjust response links/embedding/pagination

Inputs required

  • Repo root + target plugin/theme/mu-plugin (path to entrypoint).
  • Desired namespace + version (e.g. my-plugin/v1) and routes.
  • Authentication mode (cookie + nonce vs application passwords vs auth plugin).
  • Target WordPress version constraints (if below 6.9, call out).

Procedure

0) Triage and locate REST usage

  1. Run triage:
    • node skills/wp-project-triage/scripts/detect_wp_project.mjs
  2. Search for existing REST usage:
    • register_rest_route
    • WP_REST_Controller
    • rest_api_init
    • show_in_rest, rest_base, rest_controller_class

If this is a full site repo, pick the specific plugin/theme before changing code.

1) Choose the right approach

  • Expose CPT/taxonomy in wp/v2:
    • Use show_in_rest => true + rest_base if needed.
    • Optionally provide rest_controller_class.
    • Read references/custom-content-types.md.
  • Custom endpoints:
    • Use register_rest_route() on rest_api_init.
    • Prefer a controller class (WP_REST_Controller subclass) for anything non-trivial.
    • Read references/routes-and-endpoints.md and references/schema.md.

2) Register routes safely (namespaces, methods, permissions)

  • Use a unique namespace vendor/v1; avoid wp/* unless core.
  • Always provide permission_callback (use __return_true for public endpoints).
  • Use WP_REST_Server::READABLE/CREATABLE/EDITABLE/DELETABLE constants.
  • Return data via rest_ensure_response() or WP_REST_Response.
  • Return errors via WP_Error with an explicit status.

Read references/routes-and-endpoints.md.

3) Validate/sanitize request args

  • Define args with type, default, required, validate_callback, sanitize_callback.
  • Prefer JSON Schema validation with rest_validate_value_from_schema then rest_sanitize_value_from_schema.
  • Never read $_GET/$_POST directly inside endpoints; use WP_REST_Request.

Read references/schema.md.

4) Responses, fields, and links

  • Do not remove core fields from default endpoints; add fields instead.
  • Use register_rest_field for computed fields; register_meta with show_in_rest for meta.
  • For object/array meta, define schema in show_in_rest.schema.
  • If you need unfiltered post content (e.g., ToC plugins injecting HTML), request ?context=edit to access content.raw (auth required). Pair with _fields=content.raw to keep responses small.
  • Add related resource links via WP_REST_Response::add_link().

Read references/responses-and-fields.md.

5) Authentication and authorization

  • For wp-admin/JS: cookie auth + X-WP-Nonce (action wp_rest).
  • For external clients: application passwords (basic auth) or an auth plugin.
  • Use capability checks in permission_callback (authorization), not just “logged in”.

Read references/authentication.md.

6) Client-facing behavior (discovery, pagination, embeds)

  • Ensure discovery works (Link header or <link rel="https://api.w.org/">).
  • Support _fields, _embed, _method, _envelope, pagination headers.
  • Remember per_page is capped at 100.

Read references/discovery-and-params.md.

Verification

  • /wp-json/ index includes your namespace.
  • OPTIONS on your route returns schema (when provided).
  • Endpoint returns expected data; permission failures return 401/403 as appropriate.
  • CPT/taxonomy routes appear under wp/v2 when show_in_rest is true.
  • Run repo lint/tests and any PHP/JS build steps.

Failure modes / debugging

  • 404: rest_api_init not firing, route typo, or permalinks off (use ?rest_route=).
  • 401/403: missing nonce/auth, or permission_callback too strict.
  • _doing_it_wrong for missing permission_callback: add it (use __return_true if public).
  • Invalid params: missing/incorrect args schema or validation callbacks.
  • Fields missing: show_in_rest false, meta not registered, or CPT lacks custom-fields support.

Escalation

If version support or behavior is unclear, consult the REST API Handbook and core docs before inventing patterns.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.