n8n is a self-hosted pipeline builder that sits outside WordPress and connects your fleet of client sites to the rest of your operating stack. Instead of maintaining one automation setup per site, you build one pipeline and run it across every site by looping over credentials and URLs at runtime. This guide walks through connecting n8n to WordPress via REST API and webhooks, the five operational tasks worth automating first, and how to keep pipelines reliable as your fleet scales.
Single-site automation plugins scope their logic to one WordPress installation, which makes them the wrong starting point for an agency operating a fleet of client sites. Plugins that handle scheduling or per-site event routing run inside WordPress itself. Every pipeline you build lives on exactly one site, and duplicating it across twenty client sites means twenty separate maintenance obligations, twenty failure points, and no unified view of what ran and what failed.
n8n runs outside WordPress entirely. It is a self-hosted visual pipeline builder that connects external triggers, APIs, and third-party services into a single orchestration layer. From one n8n instance, you can run the same pipeline against every site in your fleet, passing each site’s URL and credentials as variables at runtime. A health check that pings all thirty of your client sites and routes failures to Slack takes one pipeline in n8n, not thirty plugin configurations.
The operational difference is architectural. Single-site automation is additive: you stack one setup per site. n8n is multiplicative: one pipeline, parameterized across the fleet. For agencies managing more than five or six client WordPress sites, that shift compounds fast. The fleet angle is where n8n pulls ahead of every per-site option, and it is why fleet-scale agency operators treat it as part of their operating layer rather than a standalone automation add-on.
WordPress exposes a REST API at /wp-json/wp/v2/ on every self-hosted installation, and that API is the primary connection point for n8n. Authentication uses Application Passwords, a core WordPress feature available since version 5.6. In the WordPress admin, navigate to Users, then Profile, generate an Application Password for a dedicated automation user, and store it in n8n’s credential store.
In n8n, the HTTP Request node handles all WordPress API calls. Set the method (GET, POST, PUT, or DELETE), point it at the full REST endpoint URL for the target site, and attach your credential. To run the same node against multiple sites, store your site URLs in a structured list (a JSON array, a Google Sheet, or an Airtable table) and loop over them using n8n’s Loop Over Items node. Each iteration passes a different site URL into the HTTP Request node, so one pipeline covers the whole fleet without modification.
For event-driven pipelines, WordPress can push data to n8n via webhooks. Install the WP Webhooks plugin on each client site, configure it to fire on a specific WordPress action (post published, plugin updated, user registered), and point it at your n8n Webhook node URL. n8n receives the payload, processes it, and routes it wherever it needs to go. One Webhook node can receive payloads from multiple client sites and use the incoming site identifier to branch or route the data accordingly.
A few operational notes before connecting your first site:
Site uptime and health checks are the highest-value starting point for any agency fleet automation. A pipeline that pings the REST API endpoint of every client site on a five-minute schedule, logs the response time, and routes any failure or degraded response to a Slack channel or email alias replaces manual checking and removes the need for a separate monitoring subscription for basic fleet coverage.
Client reporting is the second area where fleet automation pays off quickly. Pulling analytics data from Google Analytics or Jetpack Stats and pushing it to a client-facing Airtable base or Google Sheet on a weekly schedule eliminates a recurring manual task. n8n can format the data, attach a subject line, and send the report by email without human involvement, on exactly the cadence the client expects.
Plugin and core update alerts are operationally important but easy to miss across a large fleet. A pipeline that calls the WordPress update check endpoint on each site, compares current versions against available updates, and posts a consolidated summary to your project management system gives you a single view of fleet currency without logging into each site individually.
Content approval routing is worth automating when client sign-off is part of your publishing process. A webhook fires when a post moves to pending review; n8n catches it, formats a Slack message with the post title and preview link, and tags the responsible account manager. The client does not wait for someone to notice the queue.
Scheduled maintenance tasks (database optimization, transient cache clearing, log rotation) can run via the WordPress REST API or a WP-CLI wrapper. A pipeline that fires a maintenance endpoint on each site during a low-traffic window is more reliable than relying on each site’s internal cron, which depends on visitor traffic to trigger and can go silent on low-traffic client sites.
The site health check pipeline is the right first build for most agency operators: it is high-value, low-risk, and teaches the core fleet looping pattern you will reuse in every subsequent pipeline.
Start with a Schedule Trigger node set to run every five minutes. Connect it to a Set node that outputs your site list as a JSON array, each entry containing a site URL and a credential identifier. Connect that to a Loop Over Items node, which passes one site at a time to the next step.
Inside the loop, place an HTTP Request node. Point the URL at the site’s REST API root: {{$json.url}}/wp-json/. This endpoint returns a small JSON object if WordPress is responding. Set the timeout to ten seconds and enable Continue On Fail so a down site does not halt the run for every site behind it in the queue.
After the HTTP Request node, add an If node that checks the HTTP response status code. If the status is not 200, route to a Slack node that posts the site URL, the status code, and a timestamp to your team’s alert channel. If the status is 200, route to a logging step or a no-operation node.
Once this pipeline runs reliably for a week, use it as the structural template for your next automation. Replace the health check HTTP Request with whatever API call the next task requires, swap the If node condition, and update the downstream routing. The fleet looping pattern stays the same across every pipeline you build. That reusability is what makes n8n a compounding asset as your fleet grows rather than a one-time configuration cost.
The credential management pattern you pick at site five determines how painful site fifty will be. The pattern that scales: store all client site URLs and their corresponding credential identifiers in a single source of truth (a database table, an Airtable base, or a JSON file), and build every pipeline to read from that list at runtime rather than from hardcoded values inside the pipeline itself.
In n8n, each WordPress site gets its own credential entry in the credential store, named consistently. A naming convention like clientname-wordpress-prod works well. Your pipeline’s first step retrieves the list of active sites, and subsequent steps reference the credential by a naming pattern derived from the site identifier. Adding a new client site then requires one row in your site list and one credential entry, with no pipeline editing required.
For agencies already running an operating layer that tracks client site data, that system becomes the natural source of truth for the site list. Running a fleet of WordPress sites with a unified operating layer means your automation always reflects your actual client roster, not a manually maintained spreadsheet that drifts over time. WPOS Connectors can surface site metadata (URL, status, last audit date) that n8n reads at the start of each pipeline run, keeping your automation in sync with your actual operating state.
Document your credential naming convention and site list schema in a runbook. When a team member needs to add a site or rotate a credential, the runbook tells them exactly what to update and in what order. That documentation is the difference between a fleet operation that one person understands and one the whole team can maintain and extend.
n8n logs every execution with status, duration, and error detail, and reviewing that log weekly is the minimum maintenance habit for any fleet automation setup. Set up an n8n error handler using the built-in Error Trigger node: when any pipeline fails, the error trigger fires and routes the failure details (pipeline name, failed node, error message) to a Slack channel or PagerDuty alert. Silent failures are more dangerous than noisy ones in a fleet context, because one broken pipeline can affect every client site before anyone notices.
As your fleet grows past twenty or thirty sites, execution time becomes a real constraint. Pipelines that loop over sites sequentially can take several minutes to complete at scale. Split long-running pipelines into batches: process ten sites per run, stagger start times across the hour, or move to a queue-based pattern where each site triggers an independent sub-execution. n8n’s Queue Mode (available in self-hosted instances) handles concurrent executions cleanly and keeps individual runs fast even as the fleet grows.
Version your pipelines before changing them. Before modifying a production pipeline, export the current version, make changes in a staging n8n instance, test against one client site, then promote to production. A broken pipeline that touches all client sites in one run creates a bad hour that a rollback to the prior version prevents in seconds.
Plan your n8n infrastructure with fleet scale in mind from the start. A single instance on a 2-4 vCPU server handles dozens of sites without issue. Past roughly one hundred sites with frequent execution schedules, watch resource limits and consider Queue Mode with multiple worker processes. Treat the n8n instance as critical operating infrastructure, not a background service.
For agencies running WPOS as their operating layer, n8n fits in the middle tier: WordPress sites at the base, n8n pipelines connecting them upward, and the operating layer giving account managers a unified view of fleet state. See the WPOS pricing page for how the operating layer is structured for fleet-scale agencies.
n8n is a visual pipeline builder, so most common tasks (HTTP requests, loops, conditional routing, Slack and email notifications) require no code. Some advanced use cases benefit from basic JavaScript in n8n’s Code node, but the five fleet operations covered in this guide can be built and maintained by a non-developer agency operator using n8n’s built-in nodes.
For fleet-level operations that run across multiple client sites, n8n is a stronger choice than per-site plugins because it centralizes control in one instance. For single-site tasks that depend on WordPress internals directly, a per-site plugin may still be the right fit. Many agency operators use both: n8n for cross-fleet orchestration, and lightweight per-site plugins to expose the webhook endpoints or REST actions that n8n calls.
A self-hosted n8n instance on a 2-4 vCPU server handles pipelines across dozens of sites without issue. Past roughly one hundred sites with frequent execution schedules, move to n8n’s Queue Mode and allocate dedicated server resources. The bottleneck is typically concurrent execution slots and outbound HTTP rate, not n8n itself.
Use WordPress Application Passwords (built into WordPress core since version 5.6) with a dedicated, least-privilege user on each site. Store each credential in n8n’s encrypted credential store with a consistent naming convention tied to your site list. Never use admin credentials for automation, and rotate Application Passwords on a schedule documented in your team runbook.
WP-Cron fires only when a site receives a visitor request, so scheduled tasks on low-traffic client sites can be delayed or skipped entirely. n8n runs on its own server clock, so tasks fire at the exact time you set regardless of site traffic. For an agency fleet where a nightly maintenance task silently skipping on quiet sites is a real risk, that reliability difference is significant.
200 free credits. Just describe what you need.
See It In Action