Sites behind HTTP authentication

If a site is protected by a browser password prompt, the box that appears before the site loads asking for a username and password, Reviso Cloud can’t reach it and connecting the site fails.

This is common and expected. Sites still being built are exactly the sites agencies protect this way, and those are exactly the sites you want client feedback on. This page explains what to allow so the two can work together.

You may know this protection as HTTP authentication, Basic auth, htpasswd, “password protect directory”, or a staging password. It can come from your hosting control panel, your server config, a CDN like Cloudflare, or a WordPress plugin. The fix is the same in every case: allow a couple of paths through.

Why it happens

Most of Reviso works entirely from your own site outward, which HTTP authentication never blocks. But two things run the other way: Reviso Cloud calls into your site, to check the connection when you add it and to trigger an instant sync when you press Sync now.

HTTP authentication answers those calls with “password required” before WordPress even starts, so Reviso never sees the request. Cloud can only report that the site didn’t answer.

What to allow

You do not need to allow everything, and you should not. Start with the first row, and only add the others if you want what they give you.

Allow this path	What it gives you
/wp-json/reviso-cloud/v1/	Connecting the site to Cloud at all. This is the one you need.
/wp-json/reviso/v1/	Instant “Sync now” from the dashboard, instead of syncs arriving on the site’s own schedule
/wp-json/	Reviso MCP, so AI assistants can query the site (Pro only)

The rest of your site stays password protected exactly as it is. You are allowing two paths, not opening the door.

If you only allow the first one

Everything still works. You can connect the site, feedback and approvals still reach the dashboard, and central settings still apply. The only difference is that syncs arrive when the site next runs its own sync rather than the instant you press Sync now. The dashboard will tell you a sync was queued rather than live.

Is it safe to allow these?

Yes, and here is exactly why, so you can make your own call rather than take our word for it.

/wp-json/reviso-cloud/v1/ping is the only route in the first group. It answers one question: is Reviso installed here, what version, and is Cloud switched on. It returns nothing about your content, your users, or your clients.

/wp-json/reviso/v1/cloud-pull cannot be called by anyone who has not already connected your site. Every request must carry a signature made from a fresh timestamp and a secret shared only between your site and your Cloud account, and anything older than five minutes is rejected. Even with a valid signature it grants no access to data at all: it tells your site “run your sync now”, which is the same sync it already runs on a schedule.

The other routes under /wp-json/reviso/v1/ are the Reviso MCP endpoints. Each one requires a token issued to your account and refuses anything without it.

So these paths are not unprotected. They carry their own authentication, which is why putting a second password in front of them mainly stops Reviso rather than stopping an attacker.

/wp-json/ is different and worth a moment’s thought. That is WordPress’s own API index, not a Reviso path, and allowing it exposes the standard WordPress REST routes to anyone who asks. Only allow it if you want Reviso MCP, and prefer allowing it on staging rather than on a live client site.

How to allow a path

The exact steps depend on what is applying the password. A few common routes:

Hosting control panel. Look for the password protection, directory privacy, or staging password setting for the site. Many panels have an “excluded paths”, “bypass”, or “except these URLs” field. Paste the paths in there.

Cloudflare. If the prompt comes from Cloudflare Access, add a bypass policy for the paths. In Zero Trust, open the application, add a policy with the action set to Bypass, and scope it to the paths above.

nginx. Add a location block that turns auth off for the path, before the block that turns it on:

location ^~ /wp-json/reviso-cloud/ {
    auth_basic off;
    try_files $uri $uri/ /index.php?$args;
}

Apache and .htaccess. Wrap the exception in a LocationMatch, or use Satisfy Any with an allow rule for the path. Your host’s support can apply this in a minute if you would rather not edit the file.

A WordPress plugin. Check the plugin’s settings for an exclusions, whitelist, or “do not protect these URLs” field. If it has none, the plugin is applying the password inside WordPress, and it may be simpler to move the protection to your host instead.

If you are not sure which of these is applying the prompt, your host’s support will know, and this is a routine request for them.

Checking it worked

Open this in a browser, replacing the domain with your site:

https://yoursite.com/wp-json/reviso-cloud/v1/ping

If the path is allowed you will see a short line of text mentioning Reviso and a version number, with no password prompt. If you still get the password box, the exception has not taken effect yet. Some hosts and CDNs cache configuration for a few minutes.

Once that URL answers, go back to Reviso Cloud and connect the site again.

Still stuck?

Send us the site URL and tell us where the password protection comes from if you know, the host, Cloudflare, or a plugin. Email ben@getreviso.io and we will work it out with you.