How to fix the “Cannot verify request” form error

The “Cannot verify request” error appears when a visitor submits a form, and FireBox cannot confirm the submission came from a real, valid page.

Why this happens

When a Campaign loads, FireBox puts a one-time security token (a WordPress nonce) into the page. When the form is submitted, FireBox checks that token before it saves the submission. If the token is missing, old, or does not match, the submission is rejected and the visitor sees “Cannot verify request.”

A token stops matching when the page was served from a cache after the token expired, when the token was changed after the page loaded, or when the request reaches your site under a different address or login state than the page it came from. WordPress tokens last about 24 hours.

The reasons below are listed from most likely to least likely. Work down the list.

1. A caching plugin is showing an old page

This is the most common cause. A page cache saves the HTML, along with the token inside it, and shows that saved copy to later visitors after the token has expired. This can happen with any caching plugin, not only Breeze: WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, WP Fastest Cache, SG Optimizer, and others.

Fix:

1. Clear the plugin's cache (for example, Breeze > Purge All Cache).
2. Reload the Campaign page and test the form again.
3. If it happens again, exclude the pages your Campaigns appear on from page caching. Add their URLs to the plugin's “never cache” list (in Breeze: Advanced Options > Never Cache URL(s)).
4. Still not working? Turn the plugin off for a moment to confirm it is the cause, then turn it back on with the exclusions in place.

2. Your host or CDN is caching the page

Some hosts and CDNs cache the page on their own, without a plugin: SiteGround, WP Engine, Kinsta, Cloudways (Varnish), Nginx page cache, or a CDN such as Cloudflare APO, a “Cache Everything” page rule, QUIC.cloud, or Fastly.

Fix:

1. Clear the host cache from your hosting dashboard and the CDN cache from its dashboard.
2. Exclude the Campaign pages from page caching at the host or CDN level, or turn off “cache everything” for those URLs.
3. Reload the page and test again. If you are not sure which layer caches the page, ask your host which page cache is turned on.

3. A speed plugin is caching the token

Plugins that combine, defer, delay, or separately cache inline scripts can keep an old token even when page caching is off. Examples: Autoptimize, Perfmatters, WP Rocket “Delay JavaScript Execution”, and LiteSpeed inline JavaScript options.

Fix:

1. Turn off JavaScript and CSS minify and combine, and any “delay” or “defer JavaScript” option.
2. If that fixes it, turn those options back on but exclude FireBox scripts from them.
3. Clear the cache and test again.

4. The Campaign was left open too long before submitting (browser behavior)

Tokens expire after about 24 hours. If a visitor opens the popup and submits much later, such as a tab left open overnight or a device left asleep, the token has already expired by the time they submit.

Fix:

1. This is normal behavior, not a setting problem. The visitor just needs to reload the page and submit again on a fresh token.
2. If a lot of your visitors keep pages open for a long time, keep your page cache time shorter than the token time so a reload always returns a valid token.

5. The browser brought back an old page (browser behavior)

When a visitor moves to another page and presses Back (or Forward), the browser can bring back the previous page from its own memory, including the old, expired token, without asking your server for a new one.

Fix:

1. Ask the visitor to refresh the page before they submit.
2. This clears up on its own on the next real page load. No site change is needed.

6. The site was moved or its security keys changed

Changing the WordPress security keys and salts in wp-config.php makes every current token invalid right away. This often happens after moving or copying a site (staging to live) or when a security plugin changes the keys.

Fix:

1. After a move, copy, or key change, clear all caches so visitors get pages built with the new keys.
2. Ask anyone testing to reload the page. Tokens made before the change will not work.

7. A security plugin or firewall is blocking the request

Wordfence, Sucuri, Solid Security, or a host firewall (WAF) may block, rate-limit, or remove data from admin-ajax.php, which breaks the request before FireBox can check it.

Fix:

1. Turn off the security plugin or firewall rule for a moment and test the form.
2. If that fixes it, add admin-ajax.php (and FireBox's form request) to the allow list in the plugin or firewall settings instead of leaving protection off.

8. The visitor's login, session, or cookies changed (browser behavior)

The token is tied to the visitor's session, so it can fail if, between loading the page and submitting, their login expired, they logged in or out in another tab, or their browser blocks the session cookie (private/incognito mode, strict privacy settings, or a cookie-blocking extension).

Fix:

1. Ask the visitor to reload the page so a token that matches their current session is made.
2. If it only affects private mode or cookie-blocked visitors, that is a browser setting. Confirm the form works in a normal window with cookies allowed.

9. The site address is not consistent (www / https)

If the page loads on one address but the request is sent to another, such as www vs non-www or http vs https, the session cookie may not travel with the request and the token cannot be checked.

Fix:

1. Set one main address under Settings > General (WordPress Address and Site Address), matching www/non-www and https.
2. Make sure any reverse proxy or staging domain serves the same address the visitor loads.

10. Server clocks are out of sync (rare)

On sites that run on more than one server, if the servers' clocks are not in sync, a token made by one server can fail on another. Sites on a single server are not affected.

Fix:

1. Ask your host to sync the servers' clocks (NTP).

Still not working?

If the error keeps happening after you clear caches and apply the exclusions above, contact FireBox support. Tell us the plugin, hosting, and CDN you use, and whether it happens for all visitors or only some. That tells us which layer is caching or blocking the token.