Create a WordPress Draft with n8n Through the REST API

To create a WordPress draft with n8n through the API, authenticate to the correct site, send the approved content with an explicit draft status, and read the saved post back before declaring the import complete. If the article needs a new cover, upload the media and link its ID to the post. Preserve resource IDs so a failed run can resume without creating everything again.

The API response starts the check; it does not finish it. A returned ID identifies a resource. Editorial delivery also requires verifying the text, state, featured image, category, and other required fields in the destination.

Define what a complete draft contains

Start with a package contract: title, HTML body, excerpt, slug, category, tags, cover, source links, and applicable metadata. A workflow that records only “post created” cannot distinguish a complete import from one that lost the cover or used a different assignment. Specify which fields must match the reviewed files before configuring the write node.

Separate editorial production from import. The workflow described here takes reviewed files and saves drafts only. Publication is a later decision about the content actually stored. If an agent writes the article, it should not be allowed to choose the WordPress status freely or replace file approval with its own completion message.

This contract also helps when one person produces an article and another maintains the automation. The importer should receive an identifiable package rather than guess which files belong together. A missing source record or cover can then stop delivery before a partial draft is reported as ready.

Authenticate to the right account and site

WordPress REST API authentication documentation describes Application Passwords for remote API access using Basic Auth over HTTPS. Use the account login and its application password. The label assigned to an application password is not the account username. Keep TLS certificate validation in place.

The n8n WordPress credential asks for Username, Application Password, and WordPress URL for the Basic Auth path. Its documentation also mentions OAuth2 for WordPress.com. Identify whether the destination is a self-hosted installation or WordPress.com before copying a credential setup intended for the other service.

Before the first write, perform an authenticated read against the intended site and content type. Verify the account identity and permissions required to create a draft and upload media. A successful connection test does not prove the account can complete every stage. Likewise, an application password by itself does not limit an integration to draft creation; fix the status in the workflow and scope permissions where possible.

Store the secret in n8n’s credential system. Do not embed it in the article package, a screenshot, or a public example. Confirm the base URL for every request so the workflow cannot accidentally reuse the credential against another site. If a certificate check fails, diagnose the connection rather than making “ignore SSL” the normal configuration.

Choose WordPress node or HTTP Request by required fields

The WordPress node provides post creation, retrieval, and update operations. For an operation the node does not expose, n8n recommends HTTP Request against the service API. Inspect the options in your installed version instead of assuming one node is universally suitable or that the other is always necessary.

The HTTP Request node lets you configure method, authentication, body, headers, and response handling. It can be appropriate for media uploads, a custom post type, or a plugin endpoint. That flexibility also makes the route’s contract your responsibility. Confirm which fields are accepted and what the response means.

Whichever option you choose, retain the outcome of each stage. A media node returns an image ID; a later post node may replace its input with the post response. Keep both identifiers in a durable record. Label the editorial job ID, post ID, and media ID distinctly. A generic id field is unsafe when several resources are involved.

Posts and custom post types can use different routes

For ordinary posts, the WordPress Posts API documents creation through POST /wp/v2/posts and retrieval by ID. The path is relative to the REST root, usually /wp-json/. A post request can include title, content, excerpt, slug, status, taxonomies, and featured_media.

For a custom post type, the REST API guide for custom content types explains show_in_rest and rest_base. The internal post type name may differ from the exposed route. Discover the registered route instead of assuming that the standard posts endpoint or n8n’s post operation points to the desired collection.

A site may contain ordinary posts and a separate article collection. Writing to the wrong one can still return a valid API response, while the draft appears outside the intended archive or template. Include the content type and route in the job’s identity. On recovery, inspect that same resource. Finding a similar title in another collection is not proof that the intended import already happened.

Upload or reuse the featured image deliberately

The Media API reference documents creation at POST /wp/v2/media, retrieval, and fields including alt_text, source_url, and media_details. Attach the returned media ID to the post’s featured_media field. A remote image URL alone is not a substitute for that ID.

If the correct media already exists, its confirmed ID can be reused. Before uploading a new file, check its format, dimensions, composition, and name. In n8n, configure binary transfer in accordance with the Media endpoint and your HTTP Request settings. Naming a binary property does not itself upload the file bytes.

Read the media back after upload. Confirm that its served file opens, that dimensions and format are expected, and that alt text is stored where required. Body images need URLs a visitor can load; a local computer path may work while assembling the package but fail on the site. Resolve those references before the article is saved.

Save the cover ID as soon as it is verified. If a later post write fails, recovery should not automatically upload another copy. For an uncertain upload response, inspect the media library and compare the actual file. A deterministic filename helps the search, but does not establish identity by itself.

Send draft explicitly, then compare the persisted fields

A simplified payload for an ordinary post may look like this. The title and slug are fictional; add the approved IDs and fields for your site. The status is fixed to draft by the workflow, not left to an agent’s free text.

{
  "title": "Sample article",
  "slug": "sample-article",
  "status": "draft",
  "content": "<p>Reviewed article body.</p>",
  "excerpt": "Reviewed article summary."
}

After receiving the post ID, make an authenticated read request. Use edit context when your account can access the stored source values. Compare title, body, excerpt, status, featured media, and taxonomies with the approved package. If an extension sanitizes or transforms the HTML, investigate the material difference before marking the article ready.

Define what to do with a mismatch: stop, record the affected field, and return the package for correction. A numeric ID is not a substitute for comparing text and image. The post may exist while being incomplete, in the wrong state, or assembled from files that were never reviewed together.

Editorial review also needs the rendered page: cover, hyperlinks, tables, promotional card, and phone layout. REST API access does not automatically create an authenticated browser session for previewing drafts. Record which checks were proven through the API and which still require an available preview. Do not turn a local HTML render into a claim about the live theme.

Prevent duplicate drafts when a run is repeated

A title can change and can be shared by separate assignments. Use a stable editorial identity that includes the assignment, package, and destination site as your process requires. Associate it with the returned post ID and check that mapping before another create request. A related published post is a separate editorial decision; do not overwrite it merely because the title matches.

Searching by slug can help recovery, but the WordPress wp_unique_post_slug() reference notes that it does not check uniqueness for draft or pending posts. Do not present a draft slug as a database constraint that prevents two concurrent creates.

As an architectural recommendation, coordinate simultaneous executions of the same import: record work in progress, locate existing resource IDs, and resolve conflicts before another POST. A simple “look up, then create” sequence has separate steps and cannot be advertised as guaranteed exactly-once execution. If strong enforcement is necessary, implement and test it in the responsible system.

After a timeout, do not assume that no post was created. Query the destination using the identity and IDs available, then classify the result as confirmed, absent, or still uncertain. Blindly resending can create a second draft. A failure after media upload likewise does not require another upload if the first media resource exists.

Check SEO fields through the site’s real API contract

WordPress documents extension mechanisms such as custom REST endpoints and registered fields. Sending an arbitrary JSON key does not prove a plugin accepted or persisted it. Discover what the installed plugin and site actually expose. Keep tags, focus keyword, SEO title, description, and schema as separate values.

Read back every field the integration claims to save. If a plugin accepts a write but does not expose a readable value to the configured account, record that verification limit. Persisted metadata and an SEO plugin score are also different: a score may require the plugin’s own analysis path, which should be checked on its actual surface.

• Confirm site, account, content type, and route.
• Validate the package and fix the status to draft.
• Keep editorial identity and every resource ID.
• Reuse confirmed media on recovery.
• Read the saved post and compare mandatory fields.
• Treat timeouts as uncertain until the destination is checked.
• Test concurrent attempts in a controlled environment.
• Record edit link, preview outcome, and real open issues.

Start with one fictional package in a test site. Simulate failure before and after media upload, API rejection, uncertain response, and two attempts for the same job. Note which resources were created in each case. A workflow that succeeds only when every call succeeds does not yet show reliable recovery.

Frequently asked questions

I received an ID. Is the article ready?

No. The ID locates a resource. Read it back and check the editorial contract. Existence, correct content, draft state, image, and metadata are separate facts.

Can I create a custom post type through the posts endpoint?

Check the type’s exposed route. A successful write to ordinary posts does not meet the structure required by a separate article collection.

Must I upload a new cover on every attempt?

No. Reuse a confirmed media ID when it belongs to the approved file. Investigate an uncertain previous upload before creating another copy.

Can the workflow publish after creating the draft?

Only if that later action is explicitly authorized and validated. In this workflow, delivery ends with a checked draft available for human review.

Validate one complete delivery before scaling

Begin with one article and cover, track every ID, and compare the saved destination to the approved package. Then test failure recovery and repeated runs. A useful integration reduces import work while retaining content identity, state control, and responsibility for final review.