I put together my first version of this pipeline mostly out of frustration with copy-pasting AI output into WordPress by hand for every single post. n8n handles the orchestration, OpenRouter gives you model flexibility without locking into one provider, and WordPress’s REST API takes the final output straight into a draft. It sounds like a lot of moving parts, and it kind of is, but once it’s working it genuinely runs itself.
Quick Answer
- n8n handles the workflow logic — trigger, AI call, formatting, and posting — without needing custom backend code
- OpenRouter lets you swap between different AI models through one API key instead of managing separate provider accounts
- WordPress’s REST API (with an Application Password) is how n8n actually creates the draft post at the end
- Error handling and rate limit management need to be built in manually — none of these tools do it for you by default
- Start with drafts, not auto-publish, until you trust the pipeline’s output consistently
Why These Three Tools Specifically
n8n is the automation layer — it’s open source, self-hostable if you want, and has a visual workflow builder that handles branching logic and API calls without writing a full backend application. OpenRouter sits between n8n and whichever AI model you actually want to use, which matters because it means switching models later (say, moving from one provider to a cheaper or better one for a specific task) doesn’t require rebuilding your whole workflow, just changing one node’s model parameter.
WordPress’s REST API is the part most tutorials skip over, and it’s honestly where most setup problems actually happen. Getting authentication right (Application Passwords, not your actual login password) and formatting the API payload correctly for categories, tags, and featured images takes more trial and error than the AI generation part of this whole pipeline.
What You’ll Need Before Starting
- An n8n instance, either self-hosted or n8n’s cloud version
- An OpenRouter account and API key
- A WordPress site with REST API access enabled (default on most modern installs) and an Application Password generated for your user account
- Some way of triggering the workflow — a schedule, a webhook, or a manual trigger to start
Step-by-Step Setup
Step 1: Set Up Your OpenRouter Account and API Key
Sign up at OpenRouter, add credit to your account, and generate an API key from the dashboard. Note which specific model identifier you plan to use (OpenRouter lists dozens of models under one API), since you’ll need the exact model string later in your n8n HTTP request node.
Step 2: Create a New Workflow in n8n
Start with a Trigger node — a Schedule Trigger if you want this running automatically on a timer, or a Manual Trigger while you’re still testing. Don’t wire up automation until the workflow actually produces good output reliably.
Step 3: Add an HTTP Request Node to Call OpenRouter
Configure it as a POST request to https://openrouter.ai/api/v1/chat/completions, with your API key in the Authorization header as a Bearer token. The body needs your model identifier and your prompt structured as a messages array, same format as most chat completion APIs.
This is where your actual content prompt lives — whatever house style, structure, and formatting instructions you want the AI to follow go into this node’s request body, either as a static prompt or built dynamically from a previous node’s data (like a topic list you’re pulling from a spreadsheet or database).
Step 4: Add a Function or Set Node to Parse the Response
OpenRouter’s response comes back with the generated content nested inside a JSON structure, typically under choices[0].message.content. Add a node to extract just that text field, since you’ll need clean content (not the whole API response object) for the next step.
Step 5: Format Content for WordPress
If your AI output is in Markdown, you’ll likely need to convert it to HTML before WordPress ingests it cleanly, since the REST API’s content field expects HTML, not raw Markdown, unless your theme or a plugin specifically handles Markdown rendering. n8n has Markdown-to-HTML conversion available through a Function node using a simple library call, or you can prompt the model to output HTML directly instead of Markdown, which avoids the conversion step entirely.
Step 6: Add the WordPress Node to Create the Post
n8n has a built-in WordPress node — configure it with your site URL and Application Password credentials, set the resource to “Post,” operation to “Create,” and map in your title and formatted content from the previous nodes. Set the status field to “draft” rather than “publish” while you’re still validating output quality.
Step 7: Test End-to-End With a Single Manual Run
Trigger the workflow manually and check the actual WordPress draft that gets created — not just that the workflow ran without errors in n8n, but that the post looks right, formatting held up, and nothing got mangled in the Markdown-to-HTML conversion.
Common Configuration Issues
Authentication failures on the WordPress node. This almost always comes down to using your regular WordPress login password instead of a dedicated Application Password, which WordPress generates separately under Users → Profile → Application Passwords. Regular login credentials don’t work with REST API Basic Auth the same way.
Content arriving with visible Markdown syntax (like literal asterisks) inside the published post. This means the Markdown-to-HTML conversion step either got skipped or failed silently. Check that your Function node is actually running before the WordPress node in the workflow’s execution order, and that its output is properly connected to the WordPress content field, not just sitting disconnected in the workflow.
OpenRouter returning inconsistent output formatting across runs. Some models handle instruction-following inconsistently, especially around formatting requests. Adding explicit formatting instructions directly in your system prompt (not just the user prompt) tends to improve consistency, and it’s worth testing two or three different models through OpenRouter to see which one actually holds to your format most reliably before committing to one for the full pipeline.
What Actually Worked For Me
My first working version of this pipeline had no error handling at all, and it ran fine for about a week before OpenRouter had a brief outage that caused the HTTP Request node to fail silently in a way n8n didn’t flag clearly. The scheduled trigger just kept firing every day, and nothing got created, and I didn’t notice for three days because I wasn’t checking the drafts folder daily — I just assumed it was working since I hadn’t gotten any error notifications.
So the actual fix wasn’t a clever technical solution, it was just adding a Slack notification node at the end of the workflow (both on success and on failure branches, using n8n’s error handling output) so I’d actually know immediately if something broke instead of discovering it days later by accident. Not a sophisticated fix at all, but it’s the thing that turned this from “works until it silently doesn’t” into something I actually trust to run unattended.
Advanced Additions Worth Considering
Adding a review/approval step before publishing. Instead of going straight to draft, some setups pipe the generated content into a Slack or email approval step first, where a human clicks approve/reject before the WordPress node even runs. n8n supports this through wait nodes and webhook callbacks, though it adds real complexity to the workflow.
Pulling topic lists from a spreadsheet or database instead of hardcoding prompts. Connect a Google Sheets node (or Airtable, or a database node) before your OpenRouter call, so the workflow pulls the next unprocessed topic from a queue automatically rather than you manually triggering it per topic.
Adding a featured image generation step. Some setups chain in an image generation API call after the text content step, then upload that image to WordPress’s media library via a separate REST API call before attaching it as the featured image on the post.
Rate limit handling for high-volume runs. If you’re generating a lot of content in a single run, add a Wait node between iterations to avoid hitting OpenRouter’s rate limits, which vary depending on the specific model and your account tier.
Prevention Tips
- Always start new workflows in draft mode, never auto-publish, until you’ve validated output quality across a reasonable number of test runs
- Add error notifications from day one, not after something breaks silently
- Keep your OpenRouter API key and WordPress Application Password in n8n’s credential manager, not hardcoded into node parameters, for both security and easier updates later
- Version your prompts somewhere outside the workflow itself (a doc, a spreadsheet) so you can track what changed if output quality shifts unexpectedly
FAQ
Do I need to self-host n8n, or does the cloud version work fine for this? The cloud version works fine for most content pipeline use cases — self-hosting mainly matters if you need to avoid execution limits or want full control over data handling.
Can I use this same setup with a single AI provider instead of OpenRouter? Yes, you’d just point the HTTP Request node directly at that provider’s API instead — OpenRouter’s main advantage is flexibility to switch models later without rebuilding the workflow.
Does WordPress need any special plugin installed for the REST API to work? No, the REST API is built into WordPress core and enabled by default on most installs — you mainly just need Application Passwords enabled, which is also a core feature on recent WordPress versions.
What happens if the AI generates content that doesn’t match my required format? Nothing automatically catches this unless you build in a validation step — this is why testing across multiple runs before automating fully matters, and why some people add a review step before publishing.
Can this pipeline handle SEO metadata (titles, meta descriptions) as well as body content? Yes, you can extend the OpenRouter prompt to generate metadata alongside content, then map those fields to your SEO plugin’s custom fields (Yoast or Rank Math) through the WordPress node’s custom fields parameter, though this requires knowing the specific meta field names your plugin uses.
Editor’s Opinion
the wordpress rest api authentication part trips up more people then the actual ai integration does, honestly. use application passwords from the start and save yourself some head scratching. also add error notifications immediatly, dont wait untill something breaks silently to figure out you needed them, learned that one the hard way.