[wp-trac] [WordPress Trac] #64872: Add AI REST API Endpoints (`wp-ai/v1`)

[WordPress Trac]

#64872: Add AI REST API Endpoints (`wp-ai/v1`)
-------------------------+--------------------------------------
 Reporter:  gziolo       |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  7.1
Component:  AI           |    Version:  trunk
 Severity:  normal       |   Keywords:  has-patch has-unit-tests
  Focuses:  rest-api     |
-------------------------+--------------------------------------
 This ticket tracks landing the AI REST API endpoints (`wp-ai/v1`) into
 WordPress Core as a discrete unit of work for the WordPress 7.1 cycle. The
 endpoints were originally proposed as part of the broader WP AI Client
 merge (#64591) and have an existing implementation in
 [https://github.com/WordPress/wordpress-develop/pull/10915 PR #10915], but
 did not land in 7.0. This ticket scopes the REST API surface for focused
 review and iteration. The JS client is intentionally out of scope here and
 will be addressed in a separate ticket.

 == Proposed Endpoints ==

 || '''Route''' || '''Method''' || '''Description''' ||
 || `/wp-ai/v1/generate` || POST || Sends a prompt to an AI model and
 returns a `GenerativeAiResult`. Accepts messages, model config,
 provider/model selection, model preferences, and request options. ||
 || `/wp-ai/v1/is-supported` || POST || Checks whether a prompt
 configuration is supportable without running generation. ||
 || `/wp-ai/v1/providers` || GET || Lists all registered AI providers. ||
 || `/wp-ai/v1/providers/{id}` || GET || Retrieves a single provider's
 metadata. ||
 || `/wp-ai/v1/providers/{id}/models` || GET || Lists models available from
 a specific provider (requires the provider to be configured with
 credentials). ||
 || `/wp-ai/v1/providers/{id}/models/{modelId}` || GET || Retrieves a
 single model's metadata. ||

 The `generate` and `is-supported` endpoints wrap `wp_ai_client_prompt()`
 directly, ensuring consistent behavior — including the
 `wp_ai_client_allow_prompt` filter and provider resolution — between PHP
 and REST consumers.

 == Capabilities ==

 Access is gated via three meta-capabilities:

 || '''Capability''' || '''Guards''' || '''Current Default''' ||
 || `prompt_ai` || `generate`, `is-supported` || `manage_options` ||
 || `list_ai_providers` || `providers` routes || `manage_options` ||
 || `list_ai_models` || `providers/{id}/models` routes || `manage_options`
 ||

 These are implemented as `user_has_cap` filter callbacks (same pattern as
 `install_languages`, `resume_plugins`, etc.) so they can be removed and
 replaced by plugins or site-specific code.

 == JSON Schema Converter

 A small utility (`WP_AI_Client_JSON_Schema_Converter`) that converts
 standard JSON Schema `required` arrays into the per-property `required:
 true` booleans that WordPress REST API validation expects. Used to bridge
 the SDK's `getJsonSchema()` output into valid WP REST args.

 == Open question: capabilities direction

 The current approach follows the upstream plugin exactly — three separate
 meta-capabilities dynamically granted via `user_has_cap` filters to anyone
 with `manage_options`. This is simple and removable, but worth discussing:

 - **Should `prompt_ai` default to all administrators, or be more
 restrictive?** AI generation can have cost implications (API credits), and
 the current gate (`manage_options`) means any admin on a multisite network
 could generate content. Tying it to a more specific primitive capability
 or making it opt-in might be more appropriate for Core.
 - **Are `list_ai_providers` and `list_ai_models` worth separating from
 `prompt_ai`?** In practice, anyone who can prompt also needs to know
 what's available. Merging them into a single capability (or making listing
 public to all authenticated users) would simplify the permission model.
 - **Should these use `map_meta_cap` instead of `user_has_cap`?** The
 `user_has_cap` filter pattern works but is less discoverable than a
 `map_meta_cap` mapping. The Abilities API uses primitive capabilities
 stored in roles, which is the more conventional Core pattern.

 == References ==

  * [https://github.com/WordPress/wordpress-develop/pull/10915 PR #10915] —
 existing implementation (REST + JS client combined; JS client out of scope
 here)
  * #64591 — original WP AI Client merge proposal and discussion
  * [https://make.wordpress.org/core/2026/02/03/proposal-for-merging-wp-ai-
 client-into-wordpress-7-0/ Make post: Proposal for merging WP AI Client
 into WordPress 7.0]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64872>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform