How to Create WordPress REST API Drafts Without Auto-Publishing
Create WordPress REST API drafts with an explicit draft status, limited account permissions, response checks, and a separate editorial publish step.
status: "draft" when an automation creates a WordPress post, then check the returned ID and status. Use credentials whose WordPress user cannot publish if the workflow must never publish on its own. Keep the human review and publication step outside the draft-creation workflow.The API can create a post from a title, excerpt and body. The important control is the post status and the user account behind the request. A workflow that normally sends draft can still publish later if its credentials have publishing rights and another step sends publish. A prompt saying “do not publish” is not an access control.
What the create request should contain
The official Posts endpoint reference documents POST /wp/v2/posts and fields including title, content, excerpt, slug, categories and status. Always set the status explicitly. A minimal illustrative body is:
{ "title": "Draft title for editor review", "content": "<p>Working copy to verify</p>", "excerpt": "A short description for review.", "status": "draft" }This is a request-body example, not evidence that a live TopTut integration was tested. Authenticate by an approved method, send it over HTTPS, and do not place a credential in the article, URL or log. WordPress documents application passwords for external API clients and cookie/nonce authentication for code running inside WordPress.
Use permissions as the publication boundary
WordPress permissions are attached to the user account. In the default role set, a Contributor can write posts but cannot publish them; an Author can publish their own posts. The roles and capabilities guide explains that distinction. If an integration only needs to create drafts, use an account whose capabilities match that job and test the exact workflow on a disposable draft. Check any custom role or plugin changes before relying on the default role name.
An application password is a way for the application to authenticate as a WordPress user; it does not create a separate editor sign-off. A review button in an automation tool is useful for workflow, but the account’s actual publish_posts capability is the stronger boundary. Do not expand the integration account’s rights just to make an unrelated step work.
Check the response and avoid duplicate drafts
- Create one draft and inspect the API response. Record the returned post ID, status and link in the workflow log.
- If a request times out, check whether WordPress already created the post before sending another create request. A blind retry can create duplicate drafts.
- For revisions, use the documented update route for the saved post ID. Keep a source record or stable external key so the workflow knows which draft it owns.
- Stop and alert an editor if the returned status is not
draft, a category is wrong, a body is empty, or a source claim lacks evidence. Do not continue to a publish step.
The Posts reference documents both create and update routes. The safeguards above are design recommendations, not a claim that WordPress supplies an automatic duplicate-detection system. A workflow needs to keep its own returned ID and decide how to recover from an uncertain response.
Give the editor a real acceptance check
The editor should open the WordPress draft, read the entire page, verify consequential claims against sources, fix the excerpt and headings, inspect images and links, and preview the rendered post. A useful handoff records who prepared the draft, which sources were checked and which questions remain open. AI-generated text can be fluent while the evidence is missing.
Publish with a separate user action only after those checks. If the site uses Pending Review, WordPress treats that as a different status from Draft and Published; it is not itself proof that the text is correct. The status guide describes the built-in states. After publication, inspect the ordinary visitor URL because the public result can differ from the editor preview.
Frequently asked questions
How do I create a WordPress draft with the REST API?
Send a POST request to the WordPress posts endpoint with the title and content, and explicitly set the status field to draft. Check the response for the new post ID and draft status before treating the create step as complete.
What status should an automated WordPress draft use?
Use draft when the post still needs editorial work. Pending Review is a different built-in state, and publish makes the post public when the authenticated user has permission. Choose the status deliberately and verify the returned value.
Can a Contributor account publish through the WordPress REST API?
In WordPress’s default roles, a Contributor can write and manage their own posts but lacks the publish_posts capability. Check custom role and plugin changes on the actual site before relying on that boundary.
Does an application password prevent an integration from publishing?
No. An application password authenticates as its WordPress user; it does not add a separate editor approval. The user account’s capabilities determine whether a later request can publish.
How do I avoid duplicate WordPress drafts after an API timeout?
Check whether the first create request succeeded before retrying. Store the returned post ID or a stable external key, and use the update route for later revisions instead of sending a new create request blindly.
What should an editor verify before publishing an API-created draft?
Read the full post, verify important claims against sources, fix headings and excerpt, inspect images and links, and preview the rendered page. Publish with a separate authorized action, then check the ordinary public URL.
