Updated on 20 October 2026.
If you use the Semly plugin, start with its connection documentation. The diagnosis below still covers the standard WordPress REST API; an application password is not a requirement of the Semly plugin's pairing mechanism.
This procedure covers creating a post through the standard REST API of a self-hosted WordPress installation. It does not specify a Semly plugin configuration or the WordPress.com API. The goal is to locate the failure and confirm that one draft was saved.
1. Record the response and correct address
Record the HTTP method, URL without secrets, time, response status, content type and error fields code and message, if available. For standard posts, check /wp-json/wp/v2/posts. A subdirectory installation or custom post type may use a different address.
Inspect /wp-json/ for registered routes. The alternative ?rest_route=/wp/v2/posts helps investigate URL rewriting. Successful reading does not establish permission to write.
2. Separate possible causes
| Status | Check |
|---|---|
| 401 | Authentication details, HTTPS and Authorization header forwarding |
| 403 | Required capabilities, plugin restrictions, WAF or proxy rules |
| 404 | Address, method, registered route or the ID being updated |
A status alone does not establish the cause. rest_cannot_create does not prove successful authentication. A proxy can return JSON, and HTML does not prove WordPress never handled the request. Correlate the response with administrator logs.
3. Check authentication and capabilities
For a supported external connection, use a separate user-linked Application Password over HTTPS. Do not put the main account password or application secret in a support ticket. An administrator can check header forwarding without logging the Authorization value.
An authenticated request to /wp-json/wp/v2/users/me confirms user recognition, not permission to create a post. Check the capabilities for the specific content type. Saving a draft and publishing publicly are separate operations. Cookie authentication within WordPress, including its nonce requirements, differs from Application Password authentication.
4. Test a draft
In your API client, configure:
POST https://example.com/wp-json/wp/v2/posts
Content-Type: application/json
{"title":"API test","content":"Draft write test","status":"draft"}
Configure authentication in the client without embedding a secret in the shared example. Inspect the response, ID and status, then locate the draft in the dashboard. After an uncertain response, check whether the post exists before sending another POST: repeating creation can produce a duplicate.
5. Hand over and verify
Include the time, route, method, redacted response and recent configuration changes in the ticket. Do not disable an entire security layer or grant administrator access just to make the test pass. The administrator should identify the specific rule and minimum capabilities.
The fix is verified when the same test creates one draft under the intended account and its ID can be read back. Public publication is unnecessary for this diagnosis.
