Bot Protection
Bot Protection stops automated sign-ups on your journey's Signup step before they reach your CRM, your fraud-check provider or your billing system. It uses two checks that real visitors never notice (a hidden honeypot field and timing checks) plus a blocklist of addresses you have decided to refuse.
Why it matters
Scripted bots can submit a sign-up form hundreds of times an hour. Each submission can create a lead, a contact or an account downstream, and every one of them has to be cleaned up by hand. Bot Protection catches the common patterns at the form itself:
Honeypot filled — a field that is invisible to people but visible to bots got a value.
Submitted too fast — the form came back sooner than a person could fill it in.
Missing or expired form token — the submission did not come from a form we served, or the form is older than the maximum age.
These checks are deliberately simple. There is no scoring, no rules engine and no device fingerprinting. If you use a fraud-screening provider such as SEON, keep using it: Bot Protection runs first, so a caught bot never costs you a fraud check.
Turning it on for a step
Bot Protection is set on the Signup step itself, in the journey editor:
Open the journey, expand the Signup step and choose Edit field validation.
In the Bot protection card, switch protection on. It starts in Monitor.
Save, then publish the journey. Changes take effect when the journey is published.
The honeypot appears where your fields are: as a dashed chip in the Fields tray, and as a hatched, hidden field in the Live preview. Visitors never see it; it is off-screen, not focusable and ignored by password managers.
Monitor first, then Enforce
Monitor records every check that fires and lets the visitor through. Use it to see how much bot traffic you get, and whether any real visitor is ever caught, before you block anyone.
Enforce applies the action you choose under When enforced:
Flag for review — the visitor continues; the submission is flagged in the Event Log.
Block with message — the visitor sees your message and nothing is submitted.
Silent success — the journey ends on that step with your neutral message. Nothing is submitted, no later step runs, and nothing reaches your CRM or billing. The visitor is not told they were caught. Use a message that promises nothing, because a real person caught by mistake will read it.
Blocked and silently discarded sessions are counted separately and left out of your journey's conversion rates, so bots do not distort them.
Settings
Honeypot fields — 1 to 3. Use Rotate name if bots start avoiding a field.
Minimum fill time — the fastest a person could reasonably submit (default 2 seconds).
Maximum form age — how long a loaded form stays valid (default 24 hours).
The Bot Protection page
Settings → Access & Security → Bot Protection lists every journey step that has protection switched on, across all your journeys, with its mode, what happens when enforced, and how many times its checks fired in the last 7 days. Search by journey name and filter by mode; it is built for tenants with hundreds of A/B journeys. Choose a journey to open it in the editor. The page's header takes you to the Event Log and the Blocklist.
The Event Log
Settings → Access & Security → Bot Protection → Event Log lists every check that fired, with the journey, the reason, the action taken, the visitor's IP address and email domain.
Filter by reason, action and the last 7, 30 or 90 days.
Honeypot unavailable means the check could not run (for example, a custom form removed the hidden field). It is recorded so it is visible; it is never counted as clean and never blocks on its own.
Events are kept for 90 days and then deleted, because they contain personal data.
Export CSV is available to people who can edit tenant settings. Every export is recorded in the audit log.
The Blocklist
Settings → Access & Security → Bot Protection → Blocklist refuses specific senders on every protected step. Unlike the checks, a blocklist entry is your decision, so it blocks in both Monitor and Enforce, and it takes effect as soon as it is added, without publishing anything.
You can block:
Presented IP address — a single IPv4 or IPv6 address. It always expires (7 days by default, up to 90), because a bot can present a real customer's address and you don't want to lock that person out for good.
Email domain — for example a throwaway-mailbox domain. It can be permanent.
Email address — one exact address. It can be permanent.
To add one, choose Add Entry, or use a row's menu in the Event Log: Block presented IP or Block email domain opens the same dialog, already filled in. The expiry is shown before you confirm. Adding and removing entries is recorded in the audit log, and only people who can edit tenant settings see these controls.
Gotchas
Protection changes apply after you publish the journey; sessions already in progress keep the version they started on.
The IP address shown is the one the visitor presented. A bot can present someone else's address, so treat it as a lead, not proof.
Last updated
Was this helpful?