How to Allowlist IPs and Browsers in BotRefund to Stop False Positives

To configure BotRefund to allow specific IPs or browsers, edit the allowlist in the BotRefund configuration dashboard. Add the IP ranges or user-agent strings you want to treat as trusted, test each entry in debug mode first, then apply the rule globally.

BotRefund deliberately avoids calling a visitor a bot based on a single anomaly. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. The allowlist gives you a controlled override for traffic you already know is safe.

What counts as a false positive in BotRefund

A false positive is a real human visitor that BotRefund labels as a bot. It usually happens when one detection signal looks suspicious on its own. For example, a user on a shared office IP or behind a strict corporate proxy may trigger a browser API mismatch, even though the person is real.

BotRefund runs 106 independent checks for every visit. Each check adds one objective fact about the session. When a rule is too strict, a single odd fact can look like proof. That is the moment an allowlist becomes useful.

Why a single signal is not a verdict

BotRefund treats every detection signal as evidence, not as a final answer. The Console Debug Evaluator, for instance, looks for mismatches between what a real browser shows and what an automated browser often reveals. Automation tools patch or hide browser APIs, but those changes can break when the browser is inspected from another angle.

The same kind of mismatch can appear for a genuine person using a privacy extension or a corporate VPN. So BotRefund cross-checks browser, network, device, and behavior data before it decides. That design reduces false positives at the source. The allowlist is the extra layer you use for exceptions that still slip through.

When you should use an IP or browser allowlist

Use the allowlist when you have confirmed traffic that keeps getting flagged. Common candidates include:

• Staff working from a shared office IP address.
• Users behind a strict corporate proxy or firewall.
• Visitors running privacy extensions that strip standard browser API data.
• Internal QA tools or monitoring scripts that look automated.
• Regular customers connecting from a known, stable IP range.

Keep the scope narrow. Allowlisting an entire country or ISP range can admit real bots and undermine your detection.

Step 1: Build the list of exceptions

Start by reviewing the flagged sessions in your dashboard. Identify the IPs and user-agent strings that belong to your team, your office, or your known customers. Write down exactly what you see:

• The full IP address or CIDR range.
• The complete user-agent string if you plan to use one.
• A short note explaining why this traffic should be trusted.

Do this before you open the configuration panel. A clear list prevents you from adding broad or unnecessary rules.

Step 2: Add entries to the BotRefund allowlist

Open the BotRefund configuration dashboard and locate the allowlist or whitelist section. Add each entry you prepared in Step 1.

When you add an IP, use the exact address or a precise CIDR range. When you add a user agent, paste the full string the browser actually sends. A partial match may catch far more traffic than you intend, including bots that share a similar signature.

Give each entry a label so you can clean it up later. For example, “Head office static IP” or “Sales team corporate VPN.”

Step 3: Test every entry in debug mode

Before you apply anything globally, turn on debug mode. Debug mode shows you what BotRefund would have done without actually blocking or allowing anything.

Then verify three things:

1. The allowed IP is recognised as trusted.
2. The allowed browser is recognised as trusted.
3. No unrelated visitors are affected by the new rule.

Run the test from the actual IP or browser you are trying to protect. A test from your own machine may not reflect the condition of the flagged traffic.

Step 4: Apply the rule and monitor the results

Once your debug tests pass, apply the rule globally. Then watch the dashboard for the next few hours.

Confirm that the previously flagged sessions now pass. If false positives continue, the allowlist entry may not match the real signal. Reopen the flagged session and compare the IP or user agent against what you entered.

Keep an eye on your detection rate too. If you see a sudden drop in flagged sessions after applying a broad rule, you may have allowed something you did not intend.

Readiness checklist

Before you start configuring exceptions, make sure you have these in place:

• Access to the BotRefund configuration dashboard.
• The exact IP addresses or user-agent strings you plan to allow.
• Debug mode enabled and available on your plan.
• An approved owner who can review rule changes.
• A rollback plan, such as screenshots of the previous config or a documented revert process.
• A way to audit allowlist entries monthly and remove stale ones.

Key facts about BotRefund

Common mistakes when allowlisting traffic

• Allowlisting a whole country or ISP block instead of a specific IP range.
• Using a short user-agent fragment that matches more browsers than you expect.
• Skipping debug mode and applying a rule directly to production.
• Forgetting to remove entries after a team member leaves or an IP changes.
• Allowing an IP that a bot already rotates through, making the rule useless.

Limitations of IP and browser allowlisting

An allowlist is a blunt tool. IP addresses change, and a shared NAT address at an office may include a banned visitor along with the trusted team. User agents can be spoofed by bots, so relying on them alone is risky.

BotRefund’s core approach is corroboration across many signals. An allowlist overrides that reasoning, so use it sparingly and treat it as a temporary fix rather than a permanent strategy. Review your entries regularly and remove anything that no longer applies.

Frequently asked questions

How do I find the IPs I need to allow?

Look at the flagged sessions in your dashboard. The IP and user agent are recorded for each session. Match them against your known staff, office, or customer traffic.

Can I allowlist an entire browser type?

You can, but it is rarely a good idea. Bots often use the same browser type as real users. Allowlisting a whole browser can let automated traffic through untouched.

Does allowlisting reduce the strength of my refund claims?

It can, if the allowlist is broad enough to include bot traffic. BotRefund builds its refund case from verified bot sessions. An overly broad allowlist may exclude evidence from those sessions.

What should I do if a bot uses an allowlisted IP?

Remove that IP from the allowlist and report the session. Rotating bot IPs are a known pattern, so treat any mismatch as a reason to revalidate the entry.

How long does a rule change take to apply?

Rule changes typically apply within minutes, but you should confirm in the dashboard. Debug mode is the safest way to check the timing before you go live.

Should I allowlist by IP or by user agent?

Prefer IP when the range is stable and specific. User agents are easier to spoof and harder to keep precise.