How AI Fits Into the WordPress Block Editor

Every course before this one in the track puts the AI call on the backend or agent-facing side of WordPress: an ability an MCP client invokes, a PHP AI Client SDK call your own plugin code makes on the server, an external assistant reaching in over the REST API with an Application Password. This lesson draws a clear line between that world and the one this course lives in, JavaScript running inside the block editor itself, so you know exactly which pattern applies before you write your first AI-powered block in the next lesson.

What you'll learn in this lesson

Where the AI call actually originates

JS running in wp-admin, not a server-side execute_callback triggered by an external client.

How the editor authenticates its own requests

The logged-in user's cookie and REST nonce, not an Application Password.

Why apiFetch just works inside wp-admin

WordPress core already wires @wordpress/api-fetch up with the current session.

What still has to live on the server

The actual call to wp_ai_client_prompt() never runs in the browser.

Prerequisites

Course 1 (WordPress AI Foundations) is assumed background for what an ability and the PHP AI Client SDK are. Course 5 (the PHP AI Client SDK course) is helpful but not required, this course builds every server-side call it needs from scratch. Comfort with register_block_type() and JSX from ordinary Gutenberg block development is expected.

Step 1: Two different directions for the same underlying stack

Courses 1 through 8 cover two directions of AI traffic, and both point away from the browser: an AI client calling into WordPress through an ability (Courses 1 to 4), or your own WordPress PHP code calling out to a model through the PHP AI Client SDK (Course 5), triggered by a cron job, a save_post hook, or an ability’s execute_callback. In both cases, the code that talks to the AI model runs on the server, and the client on the other end, if there is one, is an external MCP client authenticated with something like an Application Password.

This course adds a third direction: JavaScript running live inside the block editor, in the same browser tab the author is typing in, calling a WordPress REST endpoint the instant they click a button. There’s no MCP client, no Application Password, and no separate authentication flow to configure. The “client” is the WordPress admin itself.

Where the AI call originates, across the track
Pattern	Where the call happens	Auth	Covered in
External AI client calling an ability	Outside WordPress entirely, over MCP	Application Password	Courses 2 to 4
Your PHP calling an AI model	Server-side, triggered by a hook or cron	N/A, server calls out directly	Course 5
Editor JS calling your own REST endpoint	Browser, inside wp-admin, live while editing	Cookie + REST nonce (this course)	This course

An Application Password exists to let something outside WordPress, a script, an MCP server, another site, prove it’s allowed to act as a given user without knowing that user’s real login password. It’s the right tool when the caller is a separate process with no existing session.

That’s not the situation here. The person clicking “Rewrite with AI” is already logged into wp-admin, already has an active session, and the browser already holds the cookies that prove it. Asking that same browser to also manage an Application Password just to call your own plugin’s REST endpoint would be solving a problem that doesn’t exist, and would be strictly worse for security, an Application Password sitting in front-end JavaScript is a credential exposed to anyone who opens dev tools.

Instead, every request your block’s JS makes goes through @wordpress/api-fetch, which WordPress core has already configured, before your code ever runs, with the current user’s REST API nonce and the site’s REST root URL. Calling apiFetch() from inside an editor script authenticates as whichever user is logged in, with whatever capabilities they actually have, no extra setup required on the JavaScript side.

// File: src/index.js
import apiFetch from '@wordpress/api-fetch';

// This request is authenticated as the current wp-admin user automatically.
apiFetch( { path: '/my-plugin/v1/rewrite', method: 'POST', data: { content: 'Some text' } } )
	.then( ( response ) => console.log( response ) );

Your permission_callback still matters

Cookie and nonce auth proves who the request is from, it doesn’t decide what they’re allowed to do. Every REST endpoint you register in this course still needs a real permission_callback, typically a current_user_can( 'edit_posts' ) check, the same capability check you’d write for any other REST route.

Step 3: What still runs on the server

Nothing about this course changes where the actual model call happens. apiFetch() reaches a REST endpoint you register in PHP, and that endpoint’s callback is what calls wp_ai_client_prompt(), exactly like Course 5. The browser never talks to an AI provider directly, it talks to your WordPress site, and your WordPress site talks to the model. The only thing this course changes is what triggers that server-side call: not a cron job, not an ability invoked by an external client, but a click inside the editor, live, while a post is being written.

Test it: confirm the editor’s own REST session

You don’t need any plugin code yet to see this in action. Open a post in the block editor, open your browser’s developer console, and run:

// Browser devtools console, on any wp-admin edit screen
wp.apiFetch( { path: '/wp/v2/users/me' } ).then( console.log );

You should see your own user object come back, with no login prompt, no token to paste in, nothing beyond what’s already loaded on the page. That’s the exact mechanism every block you build in this course relies on.

This only works inside wp-admin, not on the front end

apiFetch()’s automatic nonce and root URL wiring is set up by the block editor screens specifically. Calling apiFetch() from front-end JavaScript, on a normal visitor-facing page, won’t have that context available, and will need its own, separate REST authentication approach, which is outside the scope of this editor-focused course.

Recap

This course lives in a different part of the WordPress AI stack than Courses 1 through 8: the AI call originates from JavaScript running inside the block editor, authenticated by the logged-in user’s own cookie and REST nonce through @wordpress/api-fetch, not by an Application Password or an external MCP client. The server-side half of every feature still calls wp_ai_client_prompt() exactly as Course 5 taught, what changes is what triggers it: a click in the editor, not a cron job or an agent’s tool call. The next lesson builds a real block on top of exactly this pattern.

Resources & further reading

@wordpress/api-fetch package reference, developer.wordpress.org
REST API authentication reference, developer.wordpress.org
Introducing the AI Client in WordPress 7.0, make.wordpress.org