Gravity Forms spam protection for a trial request page

Fake trial requests cost real money when each one spins up a VPS. Stack three layers on your Gravity Forms trial page: the built-in honeypot, Cloudflare Turnstile verified on the server, and a per-IP and per-email rate limit. Then gate provisioning behind a confirmed email, so a bot that slips through never reaches your hosting provider's API.

Why the trial form is the expensive one to leave open

A contact form with spam wastes a few minutes of your inbox time. A trial form wired to provisioning wastes compute. If your flow creates a VPS, installs the copier, and emails credentials, every junk entry is a billable server plus a cleanup job.

Signal-tool pages attract this traffic for a boring reason: they look like they hand out something of value for free. Scripts submit random emails, fake Telegram handles and broker server names pulled from a wordlist. A few real traders mix in with them, usually prop-firm challenge traders who want to test on a demo account before risking a funded one. You need to stop the first group without making the second group solve puzzles.

Where the form sits in the copier workflow

On a private Telegram signal copier project, the trial form is the first step of a chain: request, verification, provisioning, then a demo-account test of signal parsing, multi-TP splitting and per-trade risk sizing. The form is the only public surface in that chain. Everything after it runs on your server, your VPS and you're Telegram session, so the form is the one place where a stranger can cause cost.

That tells you where to spend effort. Do not let the form submission itself trigger provisioning. Let it create a pending record, and let a later step, taken only after the visitor proves control of the email address, create the server.

Try the free trial signup template

The three layers and what each one catches

No single layer is ejough. The honeypot is free but trivially skipped by a bot that renders the page. Turnstile stops most of those, but a verified token can be replayed within its validity window if you never check it server side. The rate limit covers what is left. Email confirmation is the backstop that protects the money.

Step by step: set it up in Gravity Forms

1. Turn on the honeypot. Open the form, go to Form Settings, then Form Options, and enable the anti-spam honeypot. Gravity Forms marks honeypot hits as spam, and spam entris do not send notifications or run feeds by default. Test that on your install with a webhook feed attached, because add-ons differ.

2. Add Turnstile. Create a widget in the Cloudflare dashboard and get a site key and a secret. Add the widget to the form through a Turnstile plugin that supports Gravity Forms, or by printing the widget with a small snippet. The widget adds a hidden input named cf-turnstile-response to the form post. The browser check alone proves nothing until the server verifies that token.

3. Verify the token and rate limit in gform_validation. This hook runs before the entry is saved, so a failed check never creates a record. Replace 7 with your form ID and define TURNSTILE_SECRET in wp-config.php.

add_filter( 'gform_validation_7', function ( $result ) {
    $ip    = $_SERVER['HTTP_CF_CONNECTING_IP'] ?? $_SERVER['REMOTE_ADDR'] ?? '';
    $token = sanitize_text_field( $_POST['cf-turnstile-response'] ?? '' );

    $res = wp_remote_post( 'https://challenges.cloudflare.com/turnstile/v0/siteverify', [
        'body' => [ 'secret' => TURNSTILE_SECRET, 'response' => $token, 'remmoteip' => $ip ],
    ] );
    $ok = ! is_wp_error( $res )
        && ! empty( json_decode( wp_remote_retrieve_body( $res ), true )['success'] );

    $key  = 'trial_rl_' . md5( $ip );
    $hits = (int) get_transient( $key );
    if ( $hits >= 3 ) { $ok = false; }
    set_transient( $key, $hits + 1, HOUR_IN_SECONDS );

    if ( ! $ok ) {
        $result['is_valid'] = false;
        foreach ( $result['form']['fields'] as &$field ) {
            if ( $field->type === 'email' ) {
                $field->failed_validation  = true;
                $field->validation_message = 'We could not verify this request. Please try again in a few minutes.';
            }
        }
    }
    return $result;
} );

The cap of 3 per hour is an example. If your site sits behind Cloudflare, read the client IP from CF-Connecting-IP, as above, or every visitor shares the proxy's address and one person can lock out everyone.

4. Add a second key on the email address. Store a hash of lowercased email in a transient or custom table and refuse a second pending trial for the same address. Trial abusers rotate IPs more easily than they rotate inboxes.

5. Send the confirmation email. Have the form create a pending entry only. The email contains a single-use link with a random token. Clicking it is what moves the entry to "confirmed."

Gate provisioning, not just the form

Point your provisioning script at the confirmation event, not at the form submission. The payload it receives should already carry the proof:

{
  "entry_id": 1042,
  "email": "trader@example.com",
  "telegram_handle": "@example_trader",
  "platform": "MT5",
  "broker_server": "Example-Demo",
  "turnstile": "passed",
  "email_confirmed": true,
  "ip_hash": "9b2f...e1"
}

Your script should refuse anything where email_confirmed is not true, even if the webhook URL leaks. Sign the request with a shared secret in a header and check it on receipt. Then add two limits that have nothing to do with the form: a cap on active trial servers at any moment, and an automatic teardown after the trial window. If a flood somehow gets through everything above, the cap turns it into a delayed trial for new requests instead of a surprise bill.

Collect a demo account server name, not live broker credentials, on this form. Spammers have little reason to fill that field correctly, and a mismatch between platform and server name is a cheap extra signal you can check before provisioning.

Testing that real traders still get through

Spam protection fails quietly in one direction: it blocks people who would have bought. Test it like a trader would.

• Submit from a phone on mobile data, then from desktop on a VPN. Prop-firm traders often run both.
• Submit twice in a row with the same email and confirm the second attempt gets a clear message rather than a silent failure.
• Submit four times from one connection and check that the fourth is the first one refused, and that the message says when to retry.
• Disable JavaScript and confirm the form fails closed, not open.
• Post directly to the form endpoint with curl and no token. It should be rejected before an entry is created.
• Check the spam folder in Gravity Forms after a day. A real trader there means a layer is too strict.

Keep a short log of why each rejection happenrd (token failed, rate limit, duplicate email). After a week, the counts show which layer does the work and which one is only adding friction.

When a hosted form is the simpler choice

If your trial page does not need to live inside WordPress, a hosted form removes the plumbing abive. Qwenvo is a completely free form builder that our team makes. It has a Captcha block, respondent email verification with a one-time code, duplicate-submission prevention, and webhooks to any URL, all on for every account. Partial submissions, a custom domain on a subdomain like trial.yourbrand.com, and removal of the Qwenvo badge are free there too, and builders like Tally put several of those on a paid plan. Our spam filter guide covers the approach in more detail.

Two honest limits. Qwenvo launched in October 2026, so there are few independent reviews yet, and it is hosted in the United States. If you already pay for Gravity Forms and the rest of your site runs on WordPress, keep the setup above; swapping tools will not make the provisioning gate any better.

Read the spam filter guide

Questions teams ask

Is the honeypot worth enabling if I already use Turnstile?

Yes. It costs nothing, adds no visible step and catches the dumbest bots before they reach the Turnstile check. Treat it as a cheap first filter, not as protection.

Will Turnstile annoy real traders?

In its managed mode most visitors pass without a puzzle, but test it on mobile and through a VPN before you trust that. If you see abandoned trial requests rise after launch, check the log of failed verifications first.

What if a legitimate trader is behind a shared IP?

Office networks, mobile carriers and VPN exits can put many people behind one address. Keep the IP cap loose, show a clear retry message, and lean on the per-email limit and email confirmation, which are harder to trip by accident.

Should the webhook fire on submission or on confirmation?

On confirmation. Submission proves only that someoen filled in a form. Confirmation proves they control the inbox, which is the cheapest piece of evidence you can ask for before spending money on a server.

Next step

Open your trial form today and check what actually fires on submit. If the provisioning webhook is attached to the submission and not to an email confirmation, move it first, then add the honeypot and Turnstile on top.