# 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](#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](#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](#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](#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](#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](#firewalls-and-security-plugins), then [Application passwords are turned off](#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](#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)
```

1. In your security plugin or firewall, open the settings where you allow requests that would otherwise be blocked.
2. Add a rule that allows requests whose User-Agent contains `Workover/1.0 (+https://workover.io/bot)`.
3. 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.
4. 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](https://docs.patchstack.com/faq-troubleshooting/firewall/legitimate-visitors-or-pages-are-being-blocked-by-the-firewall-how-do-i-add-this-to-the-whitelist/)). Check your tool’s own documentation. If it can only allow IP addresses, it cannot reliably let Workover through: [contact support](/docs/contacting-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.

1. 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](https://developers.cloudflare.com/cloudflare-one/access-controls/service-credentials/service-tokens/).
2. 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.
3. In Workover, open the project and click **Project settings**.
4. In the **Cloudflare Access** card, paste the client ID into **Client ID** and the client secret into **Client secret**.
5. Click **Save token**. The card shows **Service token saved** and the client ID.
6. 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](#patchstack-hardening-settings).
- The site is not served over HTTPS. WordPress only offers application passwords on HTTPS sites, apart from local development environments.

To fix it:

1. Turn application passwords back on in the plugin or hosting setting that disabled them, and make sure the site loads over HTTPS.
2. In Workover, open the project and click **Project settings**.
3. 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.
4. 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.

## Related

- [Connecting your WordPress site to Workover](/docs/connecting-your-wordpress-site/)
- [How to fix a push to WordPress that failed](/docs/push-failures/)
- [Common errors](/docs/common-errors/)
- [Sync status and conflicts](/docs/sync-status-and-conflicts/)