Let Workover reach a site behind a firewall or Cloudflare Access

Workover reaches your WordPress site through the WordPress REST API (the addresses under /wp-json/), from Workover’s servers. A security plugin, a firewall or Cloudflare Access can answer those requests before WordPress does, and a hardening setting can switch off the application passwords Workover signs in with. This page shows how to let Workover through in each case. It is the page Workover opens from its How to let Workover through and How to create a service token links.

Workover does not publish a fixed IP address to allowlist. Its outgoing addresses are not stable, so an IP rule works only until they change. Older versions of this page gave an IP address: replace any rule you created from it with one of the fixes below.

Before you start: you need admin access to the security plugin, firewall or Cloudflare account in front of your site.

Find your case

When something blocks Workover, the document’s WP tab shows We cannot reach this WordPress site with the reason underneath and a How to let Workover through link. Connecting a site from Project settings shows the same reason as an error. Match what you see to a section:

What you see	Go to
This site is behind Cloudflare Access, which intercepted our request before WordPress saw it. Add a Cloudflare service token for Workover and paste it into the site connection.	Cloudflare Access
Something in front of this site answered instead of WordPress, usually a firewall or security plugin blocking our request.	Firewalls and security plugins
WordPress did not accept this, with “your site refused the connection. Application passwords are switched off for this site or for this user, so no password can authenticate until they are enabled again in WordPress.”	Application passwords are turned off
An email titled “Workover has stopped syncing with your site” that says application passwords have been switched off	Application passwords are turned off
WordPress itself says “Application passwords are not available.” or “Application passwords are not available for your account.” when you approve the connection	Application passwords are turned off
WordPress did not accept this, with “your site refused the connection (HTTP 403). WordPress did not say why…”	Firewalls and security plugins, then Application passwords are turned off if that does not fix it
The Author field in the WP tab shows No authors available	Patchstack hardening settings

Firewalls and security plugins

The requests Workover makes to your site’s REST API identify themselves in their User-Agent header with this token:

Workover/1.0 (+https://workover.io/bot)

The full User-Agent is:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Workover/1.0 (+https://workover.io/bot)

In your security plugin or firewall, open the settings where you allow requests that would otherwise be blocked.
Add a rule that allows requests whose User-Agent contains Workover/1.0 (+https://workover.io/bot).
Limit the rule to paths under /wp-json/, because any client can send any User-Agent. That covers the REST calls Workover makes, including image uploads to /wp-json/wp/v2/media when you push.
In Workover, reload the document and open its WP tab, or retry the connection from Project settings. The WP tab reads the site again when it loads, so the message clears once the site answers.

A User-Agent rule does not cover every request. When Workover copies the images in a WordPress post into a document, it downloads them with a plain browser User-Agent that does not include the Workover token, and those files are not under /wp-json/.

Not every security tool can allow requests by User-Agent. Some allow only by IP address or by URL; Patchstack’s firewall allowlist, for example, accepts IP, payload and URL rules (Patchstack’s guide). Check your tool’s own documentation. If it can only allow IP addresses, it cannot reliably let Workover through: contact support.

Patchstack hardening settings

Patchstack has two hardening options that stop Workover even when its firewall allows the request. In the Patchstack App, go to Sites > your site > Hardening and, in the general hardening settings, turn off:

Block WordPress application password feature. Workover signs in with an application password, so this blocks the connection outright.
Disable user enumeration. Workover reads the site’s users to fill the Author field in the WP tab. When that read is blocked, the field shows No authors available.

Cloudflare Access

Cloudflare Access answers Workover’s requests with a sign-in page before WordPress sees them, so the site looks disconnected even when the connection is fine. A Cloudflare service token gives Workover an identity Access accepts.

The Cloudflare Access card is on every WordPress project, including one that is not connected yet. Workover sends the token only to the exact host in the project’s Site URL, so check that it matches the address behind Access before you save the token. If it is empty or different, correct it and click Save changes first.

In the Cloudflare Zero Trust dashboard, create a service token for Workover and copy its client ID and client secret. Cloudflare’s guide: Service tokens.
In the Access application that protects your WordPress site, add a policy that includes that service token, with its action set to Service Auth. The same guide covers this.
In Workover, open the project and click Project settings.
In the Cloudflare Access card, paste the client ID into Client ID and the client secret into Client secret.
Click Save token. The card shows Service token saved and the client ID.
If the project is not connected to WordPress yet, enter the same address in the Connect to WordPress card and click Connect. If it is already connected, open a document’s WP tab to check that the site answers.

Workover sends the token with each request to your site as the CF-Access-Client-Id and CF-Access-Client-Secret headers. The secret is encrypted before it is stored and is never sent back to your browser, so the card cannot show it again. To change the token, click Replace token. To stop using one, click Remove.

Application passwords are turned off

Workover signs in to WordPress with an application password that you approve in your own WordPress admin when you connect, so Workover never receives your WordPress login password. If application passwords are unavailable, Workover cannot connect, and an existing connection stops syncing. When an existing connection stops, the workspace owner gets an email titled “Workover has stopped syncing with your site“.

The usual causes:

A security plugin or a hosting hardening setting has switched application passwords off, for the whole site or for one user. Patchstack’s setting is covered above.
The site is not served over HTTPS. WordPress only offers application passwords on HTTPS sites, apart from local development environments.

To fix it:

Turn application passwords back on in the plugin or hosting setting that disabled them, and make sure the site loads over HTTPS.
In Workover, open the project and click Project settings.
In the Connected site card, click Change site, enter the site’s own address in New site URL, and click Reconnect. If the project has never been connected, use the Connect to WordPress card and click Connect instead.
Approve the connection in your WordPress admin when Workover sends you there.

Until the site is reconnected, changes in Workover do not reach WordPress, and changes in WordPress do not appear in Workover. Nothing is lost, and both sides catch up once the connection is restored.