AIForum.

How to Test an AI API Connection from WordPress

On this page

THE SHORT ANSWER

Testing an AI connection in WordPress has two distinct layers: whether the site can talk to an AI provider, and whether the plugin's REST endpoints answer correctly for your credentials. The AI plugin's own documentation provides a direct endpoint-level check using curl, an application password, and the Abilities API route for excerpt generation. This guide walks through that procedure, the alternative cookie-and-nonce method, and how to read the response when something fails.
Quick facts

Testing an AI connection in WordPress means checking two separate layers: whether the site can reach and authenticate with an AI provider, and whether the plugin’s REST endpoints respond correctly when called with valid credentials. The WordPress AI plugin’s testing documentation covers the second layer directly, using an authenticated curl request to the Abilities API route /wp-json/wp-abilities/v1/abilities/ai/excerpt-generation/run. This article walks through that procedure, the two documented authentication methods, and how to interpret what comes back.

It is written for site administrators and technically curious practitioners who have already installed the AI plugin and connected a provider, and who now want a reproducible way to confirm that the connection actually works rather than trusting a settings screen.

What testing an AI connection actually covers

Two failure modes look identical from the WordPress admin but have different causes.

The first is the provider layer. The AI plugin adds Connectors and AI settings pages where you enter your own API credentials for an AI provider and confirm that a connection is active and ready for other AI features to use. If the credentials are wrong, expired, or the provider is unreachable, every AI feature on the site degrades at once.

The second is the endpoint layer. Even with a healthy provider connection, a REST request can still fail because of authentication, user capabilities, permalink configuration, a security plugin, or a caching layer. A green status in the settings screen does not prove that an authenticated request from outside the browser will succeed, and a successful endpoint response does not prove the model produced a good answer. Testing both layers separately is what makes the result diagnosable.

Prerequisites

The plugin’s testing guide lists three requirements before you begin:

  • A WordPress site running and reachable over HTTP, for example https://wordpress-ai.test in a local development setup.
  • Administrator account credentials for that site.
  • curl installed and available on your command line.

You will also need the AI plugin installed with a provider connected. The Learn WordPress course on connecting a provider notes that you can explore the installation flow in WordPress Playground, but that entering a real API key and confirming a working connection works best on your own WordPress site or a local development environment.

Step 1: Verify the provider connection first

Before sending any request, confirm the provider layer. Install and activate the AI plugin, then locate the Connectors and AI settings pages it adds. Apply a provider connection using your own API credentials and confirm that the connection shows as active. If the plugin cannot establish a provider connection at this stage, an endpoint test will fail for reasons that have nothing to do with your request, so fix this layer first.

Once the provider layer is confirmed, move to the endpoint layer. The rest of this guide addresses that.

Step 2: Create an application password

The documentation recommends application passwords as the primary authentication method for endpoint testing. They are scoped to a single user, can be revoked individually, and do not expose your main account password.

  1. Log into the WordPress admin.
  2. Go to Users → Your Profile.
  3. Scroll to the Application Passwords section.
  4. Create a new application password, naming it something identifiable such as “Testing”.
  5. Copy the generated password immediately. The documentation notes you will only see it once.

Keep in mind that in most WordPress installations application passwords are only accepted over HTTPS, with local development environments commonly exempted. If your test site is plain HTTP on a remote host, expect authentication to fail before you start debugging anything else.

Step 3: Send the test request

With the application password in hand, send a POST request to the excerpt generation ability. The plugin’s documentation provides this exact command:

curl -X POST "https://wordpress-ai.test/wp-json/wp-abilities/v1/abilities/ai/excerpt-generation/run" 
  -u "your-username:application-password" 
  -H "Content-Type: application/json" 
  -d '{
    "input": {
      "content": "This is a sample article about artificial intelligence and machine learning. AI has revolutionized many industries including healthcare, finance, and transportation. Machine learning algorithms can now process vast amounts of data to identify patterns and make predictions that were previously impossible."
    }
  }'

Three details matter here. The -u flag takes the username and application password joined by a colon, with no spaces. The Content-Type: application/json header is required because the body is JSON. And the payload nests the article text inside an input object under the content key, matching the ability’s expected schema.

Replace the host, username, password, and sample text with your own values. The sample content is illustrative input supplied by the documentation, not a measured benchmark.

Step 4: Read the response and confirm the result

A successful call returns a JSON response containing the generated excerpt. The observable check is straightforward: the HTTP status is a success code, the response body parses as JSON, and the returned text is a plausible excerpt of the content you submitted rather than an error object.

If you want to see the status code and headers alongside the body, add -i to the curl command. This is worth doing on the first run, because it distinguishes a genuine endpoint response from an HTML login page or a redirect injected by a security plugin.

The documentation also describes a second method using your existing browser session instead of an application password. This is useful when you want to test with the exact session and capabilities you already have open in the admin.

  1. Log into the WordPress admin in your browser.
  2. Open DevTools and switch to the Console tab.
  3. Run wpApiSettings.nonce if that object is available, and copy the nonce value.
  4. Open DevTools → Application/Storage → Cookies and copy the value of the wordpress_logged_in_[hash] cookie.
  5. Send the request with both values attached:
curl -X POST "https://wordpress-ai.test/wp-json/wp-abilities/v1/abilities/ai/excerpt-generation/run" 
  -H "Content-Type: application/json" 
  -H "X-WP-Nonce: YOUR_NONCE_HERE" 
  -H "Cookie: wordpress_logged_in_[hash]=YOUR_COOKIE_VALUE_HERE" 
  -d '{ "input": { "content": "Your sample article text goes here." } }'

Nonces and session cookies expire, so this method is best for short-lived checks rather than repeatable scripts. Treat the cookie value as a secret and mask it if you share logs publicly.

Troubleshooting common failures

The causes below are hypotheses to test in order, starting with the cheapest checks. The plugin documentation does not enumerate specific error codes, so treat the mappings as general REST API behavior rather than documented plugin behavior.

SymptomLikely causeNext check
401 UnauthorizedCredentials missing, malformed, or an application password rejected by the serverConfirm the -u value has no spaces or stray characters, that the password was copied in full, and that the site is served over HTTPS
403 ForbiddenAuthenticated user lacks the capability the ability requiresRepeat the request with an administrator account, as the documentation specifies
404 or a route-not-found errorWrong path, or the AI plugin is not activeConfirm the plugin is active and the path is exactly /wp-json/wp-abilities/v1/abilities/ai/excerpt-generation/run
Response is HTML rather than JSONA login redirect, maintenance page, or security layer intercepted the requestRe-run with -i and inspect the status line and Location header
Connection refused or TLS errorWrong hostname, local site not running, or an untrusted certificateRequest the site root with curl first to confirm basic reachability
Success status but empty or unusable textProvider-side issue rather than a transport issueReturn to the Connectors and AI settings pages and re-verify the provider connection

When you ask for help in a community thread, include the HTTP status code, the response body with secrets masked, the WordPress and AI plugin versions, and whether the provider layer reports an active connection. That combination usually narrows the cause to one of the two layers immediately.

What this test does not prove

A passing request confirms that the endpoint is reachable, that your credentials are accepted, that the user has sufficient capability, and that the ability executed far enough to return a response. It does not confirm output quality, provider rate limits, cost behavior, or latency under load. It also tests one ability only. Other abilities exposed through the Abilities API may have different input schemas, different capability requirements, or different provider dependencies.

Finally, a single successful call is not a benchmark. If you intend to compare providers or models, design that as a separate exercise with fixed prompts, recorded settings, and repeated runs, and label the results as your own measurements rather than general performance claims.

A reproducible checklist

  1. Confirm the AI plugin is active and a provider connection shows as active on the Connectors or AI settings page.
  2. Create a dedicated application password named for testing, and store it somewhere safe.
  3. Send the documented curl request to the excerpt generation ability.
  4. Record the HTTP status code, the response body with secrets masked, and the site’s WordPress and plugin versions.
  5. If the call fails, work through the troubleshooting table from cheapest check to most involved.
  6. Revoke the test application password when you are finished if it is no longer needed.

Where to go next

Once a single endpoint responds correctly, the natural next step is to explore what else your site exposes. The Learn WordPress AI course includes lessons on the Abilities API, a practical exercise for exploring your site’s abilities, the WordPress AI Client, and the MCP Adapter, plus a practical exercise on registering your own ability and exposing it through the adapter. Testing those routes follows the same pattern described here: authenticate, call the route, and read the response.

If you try this on your own setup, consider sharing your environment, the exact request you sent, the status code you received, and what resolved it. Reproducible reports from real installations are what make this kind of documentation useful to the next person debugging the same failure.

FAQ

Do I need an application password to test the endpoint?

The AI plugin documentation recommends application passwords as the primary method, but it also documents a cookie-plus-nonce alternative for testing with an existing browser session. Application passwords are better suited to repeatable checks because they do not expire with a session.

Why does my request return 401 Unauthorized?

The most common causes are a malformed -u value, an incompletely copied application password, or a site served without HTTPS, since application passwords are generally only accepted over secure connections. Verify the credential format and the site's scheme before changing anything else.

Does a successful response prove my AI provider is configured correctly?

Only partly. A success confirms the endpoint is reachable, your credentials are accepted, and the ability executed far enough to return a response. Provider-side problems such as rate limits, quota exhaustion, or degraded output quality can still exist and are better diagnosed from the Connectors and AI settings pages.

Can I run this test in WordPress Playground?

The Learn WordPress lesson notes that you can explore the installation flow in Playground, but that entering a real API key and confirming a working connection works best on your own WordPress site or a local development environment. Endpoint tests that depend on outbound provider access are therefore more reliable outside Playground.

References

  1. https://github.com/WordPress/ai/blob/develop/docs/TESTING_REST_API.md
  2. https://learn.wordpress.org/lesson/practical-connect-an-ai-provider/

Related terms

Application Password
A per-user credential generated in the WordPress profile screen that lets external tools authenticate to the REST API without exposing the account password. The AI plugin documentation recommends it for endpoint testing and notes the value is shown only once.
X-WP-Nonce
A header carrying a WordPress REST API nonce. It is used with a logged-in session cookie to authenticate requests made outside the browser, and it expires, making it suitable for short-lived manual checks.
Abilities API
The WordPress AI plugin interface that exposes named abilities, such as excerpt generation, as REST routes under /wp-json/wp-abilities/v1/abilities/.
Connectors page
A settings screen added by the AI plugin where a provider connection is applied and its active status confirmed.
MCP Adapter
A component covered in the Learn WordPress AI course that exposes registered abilities to MCP-compatible clients.

Leave a Reply

Your email address will not be published. Required fields are marked *