Protect lead submissions with Turnstile

Check new lead submissions for bots before they reach your email platform or CRM. Cloudflare Turnstile runs out of sight, so most visitors never see it. It asks for a click only when Cloudflare needs one.

You'll need access to the project's Forms & widgets settings and permission to publish. You'll also need a Cloudflare account that can manage a Turnstile widget. A Turnstile widget only runs on the hostnames you list on it in Cloudflare, so list every domain where your forms run.

Add your Turnstile keys

1. In Cloudflare's Turnstile dashboard, create or select a widget for your website's domains. The Cloudflare dashboard link in RightMessage opens it. Set its Widget Mode to Managed. With Non-interactive or Invisible, Cloudflare can't ask a doubtful visitor to check a box, so their check fails instead.
2. Copy the widget's site key.
3. In RightMessage, open Project settings (the gear at the bottom of the sidebar), then Forms & widgets.
4. Find Bot protection.
5. Paste the site key into Site key.
6. Copy the matching secret key from Cloudflare and paste it into Secret key.
7. Wait for Saved. A key that doesn't look valid shows an error under its field and isn't saved.
8. Review and publish your changes. The keys save on their own, but the section shows Goes live once you next publish until you publish.

Enlarge

Bot protection section of Forms & widgets with the Cloudflare Turnstile Site key and Secret key fieldsOriginalOriginal

Keep the secret key in its designated field, not in page code, an AI prompt, or a screenshot. The field has a visibility control. Leave it concealed when sharing your screen. RightMessage stores it for server-side checks rather than exposing it in your website snippet.

For protection to work, you need a configured site key, a published site key, and a valid matching secret. Both fields matter.

If you use Pages, forms on your pages use these same keys. Without keys, page forms have no bot check. Bot protection names your pages' addresses, such as your rightmessage.page address and any custom domain. Add them to the widget's hostnames in Cloudflare too.

Try a normal signup

1. Open the actual page containing your form or identifying question in a clean browser.
2. Submit a synthetic test contact you control.
3. Click Cloudflare's checkbox if it appears.
4. Confirm that the expected contact and mapped data reached the provider.

Complete the test on your website rather than in the dashboard preview, which doesn't make a live protected submission. The check's completion time can vary.

When a normal signup reaches your provider with its mapped data, you've checked that visitors can still sign up with protection enabled.

What visitors see

When someone submits a protected form or email question, the check runs out of sight. If Cloudflare wants them to interact, a dialog opens over the page with Cloudflare's checkbox. It closes once they've completed it.

Cloudflare's temporary failures, such as a slow network or a timeout, are retried up to three times before the check counts as failed. If it still fails:

• A form shows "We couldn't complete the security check. Please try again. If it keeps happening, turn off your VPN or ad blocker." What the visitor typed stays in the form, so they can submit again.
• An email question moves on to the next step without identifying the visitor or updating your provider.

When Cloudflare rejects the site key, or the widget doesn't list the page's hostname, forms show "Something went wrong. Please try again." instead, and the browser console names the problem.

If a submission won't go through

If Turnstile refuses to run on one of your project's hostnames because the widget doesn't list it, Bot protection shows a warning naming that hostname and when it was last seen. Forms on that hostname can't submit until you add it to the widget's hostnames in Cloudflare.

Enlarge

Bot protection section with Turnstile keys and a warning that Turnstile couldn't run on workforge.rightmessage.comOriginalOriginal

The warning comes from visitors' browsers, so it appears after someone tries to submit a form or email question there. It stays for three days after the last refusal, even once you've fixed the widget. It goes sooner if you replace the site key and publish. If you use Pages and Turnstile refuses your pages' own domain, Settings › Page domains shows the same warning beside that domain.

Check these settings first:

1. Make sure the site and secret keys belong to the same Turnstile widget.
2. Check that the widget lists the page's hostname.
3. Check that you've published the site key.
4. If the browser blocks the Turnstile script, ask your site administrator to review the error and network details.

Protected public submissions need a verified Turnstile token. If it's missing or rejected, the request receives a 422 response.

Some contact actions can look up or update a verified existing contact without a new token. They can't introduce an unchecked email address, so this isn't a way around protection for new leads.

A missing or invalid secret, or an unavailable verification service, is a setup or service failure. It doesn't mean the bot check passed. Fix the settings or investigate the service failure rather than disabling verification in application code.

Never skip server-side verification based on a public RightMessage project identifier or a header someone could forge. If a protected site won't load in the campaign editor, follow safe page-loading troubleshooting. You can use a copy of the page without weakening your site's security.

Bot protection doesn't replace consent. An Email question's consent settings still control whether RightMessage can identify someone and update your provider. Turnstile also doesn't establish that every recorded analytics event came from a person.