Requirements and responsibilities
Confirm the named WordPress site exposes public published posts at /wp-json/wp/v2/posts and choose a harmless sample article. This example reads public data with GET; drafts, private posts and authentication are out of scope. If a security control blocks that endpoint, select a documented connector or stop rather than bypassing it.
Choose a compatible xCloud Docker + NGINX server for the current n8n template, a separate HTTPS app hostname, an n8n administrator and a workflow owner. Confirm the actual dashboard form and persistent storage before installation; catalog visibility does not grant MCP install permission.
Deploy n8n through xCloud One-Click Apps · xCloud agent capability boundaries
Prepare a nonproduction destination that can store or reject a WordPress post ID uniquely, plus one owner who can inspect destination records. Set a polling interval and time zone. This five-post pilot requires fewer than five new public articles between verified runs; after a missed run or higher volume, stop automatic delivery and reconcile paginated WordPress results by ID. Keep destination credentials in n8n, not a chat prompt.
WordPress REST API posts collection · n8n Schedule Trigger · n8n HTTP Request node · n8n workflow execution history
Identify the application volumes and database, approved backup storage and a recovery window. Docker backup capture can briefly stop n8n and an in-place restore can replace newer workflows and executions; a completed backup is not proof that a missed destination record was replayed.
Back up and restore Docker apps · Docker backup operations and storage constraints
Illustrative situation
Illustrative scenario: an editorial team publishes a new public WordPress article and wants one record in its approved test destination. The n8n workflow polls the public WordPress posts REST endpoint on a schedule. A WordPress post ID identifies the record so repeated polls or retries do not create duplicates.
Choose the approach
Use the documented WordPress public posts REST collection and an n8n HTTP Request GET for this first example. It needs no WordPress application password because it reads published public posts; authenticated or private content would be a separate permission decision.
Use the WordPress numeric post ID as the destination deduplication key. Only publish the schedule after the selected destination proves that a second poll leaves one record for that ID. A webhook from a form plugin is an alternative only when that exact plugin documents outbound events.
WordPress REST API posts collection · n8n Schedule Trigger · n8n workflow execution history
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Confirm the WordPress source and n8n target
- Where
- WordPress public REST endpoint and xCloud server/site inventory
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- WordPress hostname, public test post ID, n8n app hostname and compatible Docker server
- Action
- Open the public WordPress posts endpoint in a signed-out browser and identify one published test post ID and URL. Confirm the current n8n template, server capacity and separate app hostname in xCloud.
- Expected result
- A readable public post source and an eligible n8n deployment target.
- Verify
- Compare the REST post ID and link with the public article, then verify exact xCloud team/server IDs.
- If it fails
- If the REST endpoint is blocked or returns private data, stop and resolve the WordPress access policy before building the workflow.
Sources: WordPress REST API posts collection · Deploy n8n through xCloud One-Click Apps · xCloud agent capability boundaries
Step 2 of 5
Install n8n through the dashboard
- Where
- xCloud Add Site → One-Click Apps
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Approved n8n template, Docker + NGINX server, app hostname and first administrator recipient
- Action
- Use the current dashboard one-click n8n flow, wait for terminal installation, then record the site ID and first-run URL. The app administrator secures login separately before workflow editing.
- Expected result
- A reachable n8n application at its own HTTPS host.
- Verify
- Open the app URL and confirm administrator sign-in without changing the WordPress site.
- If it fails
- If installation fails, inspect task status and storage before repeating creation; do not treat catalog listing as MCP install permission.
Sources: Deploy n8n through xCloud One-Click Apps · xCloud agent capability boundaries
Step 3 of 5
Build a safe WordPress post poll
- Where
- n8n editor: Schedule Trigger → HTTP Request → selected test destination
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Public WordPress posts URL, schedule time zone, one known post ID and destination unique-key rule
- Action
- Set a low-frequency Schedule Trigger, then make an HTTP Request GET to /wp-json/wp/v2/posts?per_page=5&orderby=date&order=desc. Iterate every returned post item, map each ID, title and link to a nonproduction destination, and upsert or reject duplicates by ID. Use the known post only to verify the mapping. Run the full workflow manually twice before publishing.
- Expected result
- Each returned public post yields at most one destination record across repeated manual runs.
- Verify
- Match the known WordPress post ID and link to both n8n executions and exactly one destination record; inspect the other returned IDs too.
- If it fails
- If the GET fails or duplicate records appear, leave the schedule unpublished and correct endpoint, mapping or destination uniqueness.
Sources: WordPress REST API posts collection · n8n Schedule Trigger · n8n HTTP Request node · n8n workflow execution history
Step 4 of 5
Publish and observe the scheduled run
- Where
- n8n workflow editor and Executions; WordPress public post
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Reviewed workflow, schedule/time zone, destination ID and failure-notification owner
- Action
- Publish the workflow after the two-run deduplication check. Publish one harmless WordPress test article and observe the next scheduled execution, then compare its new ID with the destination. If a run was missed or five or more posts appeared since the last verified run, pause delivery and reconcile paginated WordPress results by ID before resuming. Test a failed GET with a temporary invalid URL in an isolated draft, not the live site.
- Expected result
- One new public article produces one intended destination record and failures are visible to the owner.
- Verify
- Match post ID, execution time and destination ID; check the failed draft run appears with an actionable error.
- If it fails
- If the schedule misses, five or more posts appear between runs, or the destination lacks an article, pause delivery and compare paginated source IDs with destination IDs before replaying only missing records.
Sources: WordPress REST API posts collection · n8n Schedule Trigger · n8n HTTP Request node · n8n workflow execution history
Step 5 of 5
Protect workflow state and hand over replay
- Where
- xCloud Docker backup history, n8n Executions and editorial runbook
- Permissions
- Authorized owner or administrator for the named team, site and application.
- Inputs
- Completed backup ID, workflow owner, post IDs processed and destination access
- Action
- Verify persistent n8n data is included in a completed Docker backup. Assign a person to compare new WordPress post IDs with execution and destination records after outages or credential changes. Document how to pause the schedule and insert only missing IDs after a restore.
- Expected result
- A named owner can identify the last good workflow state and recover missing records without duplicates.
- Verify
- Have the owner locate the backup, a recent execution and the destination entry for the sample post.
- If it fails
- If a backup or destination comparison is unavailable, keep the workflow in a monitored pilot and record the untested recovery gap.
Sources: Back up and restore Docker apps · Docker backup operations and storage constraints · n8n workflow execution history · WordPress REST API posts collection
Maintenance
After each WordPress URL, REST policy, n8n version or destination-schema change, run a marked public post through the poll and compare its post ID across source, execution and destination. The editorial owner checks that fewer than five posts appeared since the last verified run; a missed run or five-or-more burst triggers a pause and paginated ID reconciliation.
WordPress REST API posts collection · n8n workflow execution history · n8n Schedule Trigger
Check completed Docker backups in the agreed window and confirm the destination’s unique-ID rule remains in force. The xCloud host can be healthy while the WordPress GET or destination write fails.
Recovery decisions
After an outage, pause the n8n schedule and list public WordPress post IDs published since the last successful execution. Start at /wp-json/wp/v2/posts?per_page=5&orderby=date&order=desc&page=1 and increment page with the same parameters until the last verified post ID is reached. Compare source IDs with destination records before any retry. If the anchor is missing or posts changed during paging, stop and reconcile the complete affected publication list with the editorial owner. Preserve current workflow and destination evidence.
WordPress REST API posts collection · n8n workflow execution history
Restore n8n only for damaged application state through the authorized dashboard path; an in-place restore can replace newer workflow data. After recovery, reapply any missing credentials through the app owner, run a safe GET and insert only missing post IDs before re-publishing the schedule.
Back up and restore Docker apps · xCloud agent capability boundaries · n8n HTTP Request node
AI handoff
Connect xCloud MCP in an agent client and select the intended team. Discover the current tools, schemas and scopes. Use reads for inventory; present exact site, server, domain, cost, interruption and data impact before each approved write. Use returned dashboard_url values for manual work. The packaged REST fallback accepts GET requests only; never use it for writes.
Supported scope
- Confirm requirements and inspect resources mcp · read
Discover the connected profile and operation schema first; only teams granted to the connection are visible.
Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.
Operation identifiers and scopes to discover
teams.index, servers.show, sites.show
Scopes: read:servers, read:sites
xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
- Install n8n or Nextcloud in the dashboard dashboard · manual
The v4.4.2 capability review found n8n and Nextcloud listed in the catalog but unavailable to oneclickApps.install; use Add site → One-Click Apps.
Checkpoint: Confirm compatible Docker + NGINX server, app, resources, domain and install inputs before dashboard creation.
xCloud agent capability boundaries · Deploy n8n through xCloud One-Click Apps · Set up Nextcloud with One Click on xCloud
- Configure and test application behavior app · manual
xCloud hosting operations do not configure WooCommerce checkout, n8n workflows, Nextcloud sharing policy or application users.
Checkpoint: An application administrator verifies each real business journey and records observed outcomes.
WooCommerce testing orders · n8n Webhook node and test/production URLs · Nextcloud file sharing administration · xCloud agent capability boundaries
- Create and inspect Docker backups mcp · write
Backup capture briefly stops the app. Use supported local, S3-compatible or SFTP storage; the packaged REST wrapper is GET-only.
Checkpoint: Confirm site, storage, retention and the interruption window before creating a backup or changing settings. Check terminal completion.
Operation identifiers and scopes to discover
sites.docker.backup, sites.docker.backups, sites.docker.backupSettings.update
Scopes: read:sites, write:sites
Docker backup operations and storage constraints · Back up and restore Docker apps
- Restore a backup dashboard · manual
Native and Docker restore operations are dashboard-only. An in-place Docker restore replaces current data.
Checkpoint: Use Site → Site Backup → Previous Backups → Restore Backup (or Restore to Another Site where offered). Confirm exact target and recovery point before proceeding.
xCloud agent capability boundaries · Back up and restore Docker apps
Copyable agent brief
Manual checkpoints
- The xCloud owner installs n8n in the dashboard; its administrator secures first-run access.
- The WordPress owner confirms public REST scope and publishes a harmless test article.
- The n8n owner builds, tests and publishes the scheduled workflow and destination unique-key rule.
- The authorized owner performs any Docker restore in the dashboard after reconciling newer post IDs.
Feature coverage
- WordPress source and deployment (covered): Checks public post REST data and dashboard-only n8n deployment. Confirm the WordPress source and n8n target Install n8n through the dashboard
- task workflow (covered): Builds and deduplicates a scheduled WordPress post read. Build a safe WordPress post poll
- production acceptance (covered): Matches one new article to an execution and destination record. Publish and observe the scheduled run
- operations and recovery (covered): Names backup owner and missing-post replay rule. Protect workflow state and hand over replay
Sources
- WordPress REST API posts collection
- Deploy n8n through xCloud One-Click Apps
- xCloud agent capability boundaries
- n8n Schedule Trigger
- n8n HTTP Request node
- n8n workflow execution history
- Back up and restore Docker apps
- Docker backup operations and storage constraints
- xCloud MCP documentation and connection profiles
- Set up Nextcloud with One Click on xCloud
- WooCommerce testing orders
- n8n Webhook node and test/production URLs
- Nextcloud file sharing administration