IP Whitelisting

Admins can whitelist IP addresses so that requests from those IPs can skip certain checks (e.g. rate limiting, block-list enforcement). Whitelisted IPs are stored in the WhitelistedIPs table.

An IP cannot be both whitelisted and blocked. If you try to whitelist an IP that is on the block list (or block an IP that is whitelisted), the API returns an error and you must remove it from the other list first. See IP Blocking.

Intended use: When you add an IP to the whitelist, the worker can treat it as trusted and bypass selected validations or limits. If you set Usage to "Testing leads", submissions from that IP are not stored in Leads/LeadSubmissions; they are stored in the TestingLeads table (like BlockedIPLeads) and sent to Make.com with test_lead: yes in the payload so you get clear separation. Use "Internal (actual leads)" for real internal traffic that is stored in Leads as normal. Test leads can also be triggered by content: if name, email, project, or location contains any of the strings configured in Settings → Test lead by content, the lead is treated the same way (TestingLeads + optional Make.com with test_lead yes); see Settings.

Whitelisted IPs dashboard section

At Dashboard → Whitelisted IPs (/whitelisted-ips):

• List — All whitelisted IPs with Usage (Testing leads / Internal actual), optional note, and whitelisted-at. Filter by IP and paginate.
• Whitelist an IP — Form to add a new whitelisted IP with Usage (Testing leads vs Internal actual lead sending), optional note (e.g. "Internal office", "CI server").
• Remove — Remove an IP from the whitelist.

Usage indicates whether the IP is used for testing lead sending or for actual lead sending from your internal system. Use this to treat test vs real traffic differently in your worker logic if needed.

API

All whitelisted-IP endpoints require the analytics API key. See Analytics API – Whitelisted IPs.

Method	Endpoint	Description
GET	/analytics/whitelisted-ips	List whitelisted IPs (optional ?ip=, ?limit, ?offset; returns whitelisted_ips and total)
POST	/analytics/whitelisted-ips	Add an IP to the whitelist (body: ip, optional note, usage: test | internal)
DELETE	/analytics/whitelisted-ips/:ip	Remove an IP from the whitelist (IP URL-encoded in path)

Database

• Migration 027 — Creates WhitelistedIPs with Ip (primary key), WhitelistedAt, Note.
• Migration 028 — Adds Usage to WhitelistedIPs. Values: test (testing lead sending) or internal (actual lead sending from internal system). Default internal.
• Migration 029 — Creates TestingLeads (same structure as BlockedIPLeads). Submissions from IPs whitelisted with usage test are stored here and sent to Make.com with test_lead: yes; they are not inserted into Leads/LeadSubmissions.
• Migration 031 — Adds DeletedAt to TestingLeads and BlockedIPLeads for soft delete (see IP Blocking).

Apply with scripts/apply-local-migrations.sh or scripts/apply-production-migrations.sh.

Testing leads (usage "test")

When a submission comes from an IP whitelisted with Usage = "Testing leads":

1. The lead is not inserted into Leads or LeadSubmissions.
2. A row is inserted into TestingLeads (for audit and the dashboard).
3. If SEND_TEST_LEADS_TO_MAKE is not false (see Settings), the same payload is sent to Make.com with test_lead: 'yes' so Make.com can separate test from real leads. Set SEND_TEST_LEADS_TO_MAKE = false in wrangler to store test leads in TestingLeads only (no Make.com webhook).
4. The client receives the same success/redirect response.

Same project, same IP (team testing): Duplicate detection and re-engage logic do not run for whitelisted testing IPs. The request is handled before handleLead (which does project + identity lookup). So every submit from the same whitelisted IP for the same project creates a new row in TestingLeads and triggers a Make.com webhook (in production) each time. This lets the team test the full flow repeatedly without polluting Leads/LeadSubmissions; Make.com can filter by test_lead: 'yes' to ignore or route test traffic.

Dashboard Testing leads (/testing-leads) lists these submissions with filter by IP and quick date range. Use row checkboxes and Remove selected to hide chosen submissions from the listing (soft delete: rows are marked in the DB and retained for later analysis).

Using the whitelist in code

The worker exposes in leadAnalyticsService:

• isIpWhitelisted(env, ip) — returns true if the IP is whitelisted. Use before applying rate limits or block checks.
• getWhitelistedIpUsage(env, ip) — returns 'test' | 'internal' | null. Used in /lead.capture to route test-IP submissions to TestingLeads + Make.com with test_lead yes.

Implement bypass or different limits in other handlers (e.g. tracking) as needed.