Allow RightMessage to load your site in the visual editor
If the RightMessage visual editor shows a blank page, a fetch error, or a security challenge instead of your website, your site's security tools are probably blocking RightMessage from loading the page through our backend.
This can happen when you first create a campaign or when you reopen an existing one later.
Why RightMessage loads your page through our backend
To power the visual editor, RightMessage needs to load your page on our side first. That lets us render the page inside the editor, inspect the HTML, and make point-and-click editing possible.
Because that request comes from RightMessage instead of from a normal visitor's browser, bot protection, firewalls, and challenge systems can sometimes block it even when your website works normally for human visitors.
What to share with your developer or server team
Request header:
X-RightMessage-RoverExpected header value:
RM-{your-project-id}(replace this with your actual RightMessage project ID)RightMessage server IP:
143.198.171.122Fallback User-Agent sometimes used by RightMessage:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Need help finding your project ID? See How to find your project ID in RightMessage.
Depending on how your site is protected, the best fix may be header-based, IP-based, or both.
Best fix order
Allow RightMessage by header if your stack supports custom rules or middleware. This is usually the safest and most precise fix.
Allow RightMessage by static IP if your firewall, hosting provider, or security plugin mainly works from IP allowlists.
If your provider only offers broad bot blocking with no exceptions, temporarily disable that protection while editing, or move to a setup that supports scoped exceptions.
Cloudflare-specific guidance
If you use Cloudflare WAF custom rules, Super Bot Fight Mode, or Bot Management, ask your team to create a scoped allow or skip rule for RightMessage editor requests. Header-based rules are usually better than broad IP allow rules when they are available.
If your team says the requests come through a generic gateway and they cannot rely on IP-based allowlisting, use the X-RightMessage-Rover header path instead.
If you only use plain Bot Fight Mode and Cloudflare does not let you create per-request exceptions in your setup, you may need to disable that protection during editing or change your Cloudflare security setup.
Cloudflare Turnstile
If your page shows a Turnstile challenge inside the editor, you need to skip Turnstile for RightMessage editor requests. That means two things:
Do not render the Turnstile widget for requests where
X-RightMessage-Rovermatches your project identifier.Do not run server-side Turnstile verification for those same requests.
If you only remove the widget but still run server-side verification, the page may load but form actions in the editor can still fail.
How to find your project ID
Your project ID is the RightMessage project ID shown in your dashboard URL. Your header value should be RM-{your-project-id}, using your actual project ID.
You can also use How to find your project ID in RightMessage if you want step-by-step instructions.
After your team makes the change
Reload the page in the RightMessage editor.
If it still fails, reopen the campaign and try again.
If it still fails after that, send your developer's exact status code or security error to support.
Still stuck?
If your developer is unsure whether they should allow by header or IP, send us the security product you are using, for example Cloudflare, Wordfence, Sucuri, ModSecurity, or your hosting firewall, along with the exact error they see.