> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/settings/access-security/bot-protection.md). # 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: 1. Open the journey, expand the **Signup** step and choose **Edit field validation**. 2. In the **Bot protection** card, switch protection on. It starts in **Monitor**. 3. 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.peakcommerce.com/product/settings/access-security/bot-protection.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.