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.testin a local development setup. - Administrator account credentials for that site.
curlinstalled 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.
- Log into the WordPress admin.
- Go to Users → Your Profile.
- Scroll to the Application Passwords section.
- Create a new application password, naming it something identifiable such as “Testing”.
- 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.
Alternative: cookie authentication with a nonce
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.
- Log into the WordPress admin in your browser.
- Open DevTools and switch to the Console tab.
- Run
wpApiSettings.nonceif that object is available, and copy the nonce value. - Open DevTools → Application/Storage → Cookies and copy the value of the
wordpress_logged_in_[hash]cookie. - 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.
| Symptom | Likely cause | Next check |
|---|---|---|
| 401 Unauthorized | Credentials missing, malformed, or an application password rejected by the server | Confirm 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 Forbidden | Authenticated user lacks the capability the ability requires | Repeat the request with an administrator account, as the documentation specifies |
| 404 or a route-not-found error | Wrong path, or the AI plugin is not active | Confirm the plugin is active and the path is exactly /wp-json/wp-abilities/v1/abilities/ai/excerpt-generation/run |
| Response is HTML rather than JSON | A login redirect, maintenance page, or security layer intercepted the request | Re-run with -i and inspect the status line and Location header |
| Connection refused or TLS error | Wrong hostname, local site not running, or an untrusted certificate | Request the site root with curl first to confirm basic reachability |
| Success status but empty or unusable text | Provider-side issue rather than a transport issue | Return 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
- Confirm the AI plugin is active and a provider connection shows as active on the Connectors or AI settings page.
- Create a dedicated application password named for testing, and store it somewhere safe.
- Send the documented curl request to the excerpt generation ability.
- Record the HTTP status code, the response body with secrets masked, and the site’s WordPress and plugin versions.
- If the call fails, work through the troubleshooting table from cheapest check to most involved.
- 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.