WordPress REST API Permissions for AI
The WordPress user remains authoritative
The bridge dispatches an operation through WordPress’s REST system as the authenticated user. The target endpoint’s permission callback still runs. A conversational interface is not a substitute for these checks and should not be treated as a way to bypass them.
Choose a dedicated user for the workflow. When you see a permission denial, first ask whether the user is supposed to have that capability. A denied settings request may be the correct result for a content-focused account.
Read and write are different decisions
A read-only workspace omits the write tool from its advertised tools. The companion’s read-only option also blocks non-read dispatch. This allows a site owner to approve a content inventory or draft review without automatically permitting publication.
Once writes are enabled, the native WordPress user still needs the relevant capability. Turning off read-only does not turn a subscriber into an administrator.
Installed endpoints define compatibility
Core posts, pages and users expose familiar REST endpoints, but additional plugins define their own routes and controls. Discover the route list and parameter schema on the actual site before invoking a plugin-specific task.
A plugin interface visible in the WordPress dashboard does not necessarily mean that the same action is available through a REST endpoint. When compatibility matters to a purchase, validate it on staging rather than rely on a broad “works with everything” statement.
Plan for revocation and review
Application passwords can be revoked without sharing the main WordPress login. Disconnect the client when it should no longer use the workspace, and ask the operator to suspend an account when required.
For important changes, use a staging site, backups and precise instructions. Permission checks limit what an account may do, but they do not decide whether an allowed edit is editorially correct.
Review the security page for account boundaries and the onboarding steps for a concrete verification flow.
Which WordPress role should an AI connector use?
Short answer: Choose a dedicated user with the least access necessary for the specific task. WordPress capabilities determine what an authenticated REST endpoint allows, and plugin-defined permissions may add further requirements.
| WordPress role | Typical use in an AI workflow | Permission caution |
|---|---|---|
| Subscriber | Limited account-level or personal-data operations | Cannot be assumed to read private editorial drafts or publish content |
| Contributor | Prepare draft content within its assigned rights | Publication normally needs an authorized editor or administrator |
| Author | Manage posts they are authorized to create and publish | Does not automatically manage other authors’ posts or site settings |
| Editor | Review and manage wider editorial content | Administrative plugin or server settings may remain unavailable |
| Administrator | Site configuration and tasks requiring broad capabilities | High impact; avoid for routine read-only inventories when a smaller role works |
These are typical WordPress role expectations, not a guarantee about a customized site. Check the connected user’s real capabilities and the endpoint’s permission callback.
Understanding REST permission errors
401 Unauthorized: authentication is missing or invalid
Check the intended site, WordPress username, active Application Password or client grant and the handling of authorization headers. Do not paste credentials into a public troubleshooting message.
403 Forbidden: the authenticated operation is not allowed
A valid connection can still be denied because a WordPress role cannot perform the requested action or because a read-only control blocks writes. Do not automatically escalate the account to Administrator.
404 Not Found: the endpoint or resource may not exist
Discover the registered REST routes and confirm the namespace and resource ID. Some plugins expose WordPress dashboard controls without providing corresponding REST endpoints.
Example: review drafts without granting publishing rights
- Choose the intended WordPress site and record its returned ID and URL.
- Confirm the connected WordPress user and verify that they are allowed to view the target drafts.
- Read
/wp/v2/postswith the permitted draft-status filter and reasonable pagination. - Return the actual IDs and titles found. If the endpoint denies the request, report the error rather than inventing a draft list.
- Leave writing disabled unless a separately approved editing task requires it.
For a worked editing procedure, see the WordPress AI workflow examples. Review the WordPress REST API authentication documentation for platform details.