ReleaseWPChangeSync 2.1 is here →
Docs/Remotes & REST API

Remotes & REST API

Use remotes, REST endpoints, webhooks, and compatibility checks for site-to-site sync.
Updated July 2026·WPChangeSync 2.1

Remote sync

Remotes let one WPChangeSync site communicate with another authenticated WPChangeSync site. They are used for push, pull, workflow steps, remote groups, network-controlled rollouts, and CI-triggered release paths.

A remote should point to the target site REST base, normally https://example.com/wp-json/wpchangesync/v1. Use HTTPS and a WordPress account with the minimum required capabilities for the operation.

REST namespaces

The canonical namespace is wpchangesync/v1. The legacy bricks-sync/v1 namespace remains available for backwards compatibility with older BricksSync-era clients and integrations.

NamespaceStatusUse
wpchangesync/v1CurrentUse for all new remotes, CI calls, workflow webhooks, and integrations.
bricks-sync/v1CompatibilityKeep only for existing integrations that still call the old namespace.

Main endpoint families

Endpoint familyPurpose
/info, /status, /healthConnection tests, version checks, license status, and environment health.
/export, /importTransfer integration payloads between authenticated sites.
/integrationsList integration metadata and handler capabilities.
/workflow/*Create, inspect, run, dry-run, approve, or reject workflow operations where enabled.
/webhook/<workflow_id>Trigger a workflow from CI or an external automation using its webhook token.
/batch/*Manage larger batch jobs, progress, pause/resume, retries, and logs.
/bundles/*Create, update, export, import, and reuse workflow or item bundles.

Health checks. Two endpoints exist for monitoring rather than syncing: /health for a basic check, which needs no authentication and simply returns an OK status, and /health/detailed for fuller diagnostics. The basic one is what you point an uptime monitor or a deploy smoke test at.

The API is rate limited to 60 requests per minute. That is rarely an issue in normal use, but it can be while developing against the API, so it can be lifted with define('WPCHANGESYNC_DISABLE_RATE_LIMIT', true); in a development environment only.

Remote base examples
https://production.example.com/wp-json/wpchangesync/v1
https://client.example.com/wp-json/wpchangesync/v1/health
https://client.example.com/wp-json/wpchangesync/v1/webhook/<workflow_id>?token=<token>

Security checklist

  • Use HTTPS for every remote.
  • Use application passwords or an equivalent admin-capable authentication method; do not reuse personal passwords.
  • Limit remote users to trusted administrators and rotate credentials after staff or vendor changes.
  • Use dry-runs before production imports and require approvals for destructive or broad workflow steps.
  • Keep version compatibility aligned. WPChangeSync uses a minimum compatible remote version check.
  • Watch rate limits, server timeouts, and batch settings on large media or multisite operations.
  • Do not expose webhook tokens in public repos, issue trackers, screenshots, or client chat.

Troubleshooting remotes

If a remote fails, start with the Health or Test Connection action, then check authentication, HTTPS, application-password permissions, security plugins, REST restrictions, maintenance mode, firewall rules, and version compatibility.

See Fix Remote Connection Issues and Trigger Workflows from CI via Webhook.

Editor push and pull

Remotes also power the Push and Pull buttons in the post editor. Editor push and pull is off by default on each remote: turn it on with the Allow editor Push and Pull switch, and control who sees the buttons with the editor visibility setting. See Editor Actions for the in-editor workflow.