For site owners and security teams
Letting the Snapshot Service through
Hand this page to your platform or security team. The safest rule: allow our IP addresses and require the secret header. Draft for the pilot.
"Tested" means we ran it on a real setup. "From vendor documentation" means the steps follow the vendor's docs but we have not yet tested them. Today no recipe on this page is marked tested.
How to recognise us
| IPv4 | 91.99.153.175 (pilot; the dedicated service address is announced before it changes) |
|---|---|
| IPv6 | 2a01:4f8:c012:b85c::/64 |
| User agent | a normal Chrome user agent ending in SnapshotService/<version> (+<bot page>) |
| Optional secret header | X-Snapshot-Token: <your project token> |
| Googlebot profiles (if switched on) | Google's Googlebot user-agent strings, from the IPs above, with the secret header |
Step 1: prove the domain is yours
Verification comes first, see the verification page (Google Search Console, company email, or DNS TXT).
Step 2: let us through your protection
Run the access check in the project setup first. If every profile is green, you are done. If it is red, it names the protection it met.
Cloudflare Free (Bot Fight Mode)
from vendor documentationCustom rules cannot skip Bot Fight Mode. Use an IP Access Rule: Security, WAF, Tools, IP Access Rules. Value is our IPv4, action Allow, this website. Repeat for the IPv6 range.
Cloudflare Pro, Business, Enterprise
from vendor documentationEither the IP Access Rule above, or a custom rule: source IP is one of our addresses (and, recommended, header X-Snapshot-Token equals your token), action Skip with all remaining custom rules, rate limiting, Super Bot Fight Mode, managed rules, Browser Integrity Check, Security Level and User Agent Blocking. Place it first.
Cloudflare with our Googlebot profiles
The managed "Fake Google Bot" rule flags a Googlebot user agent from a non-Google address. The Skip rule must include managed rules and sit before the managed ruleset. Otherwise only the Googlebot profiles fail.
Akamai Bot Manager
from a third-party guideDefine us as a custom bot (user-agent token plus our IP addresses) in a custom category under Security Policies, Bot Management, and set that category to allow or monitor.
DataDome
from vendor documentationAccess Control, Custom Rules: new rule for our IP addresses with action Allow, priority above the blocking rules.
HUMAN (PerimeterX)
from vendor documentationSecurity Policy, Policy rules, Known bots and crawlers: an allow rule combining our user-agent token with an IP condition. A user-agent-only rule can be abused.
AWS WAF with Bot Control
from vendor documentationCreate an IP set with our addresses and an Allow rule on it with a lower priority number than the Bot Control rule group.
Vercel
from vendor documentationProject, Firewall, Add New, System Bypass for our addresses. If Bot Protection is on, add a WAF custom rule with action Bypass for our addresses.
F5 Distributed Cloud Bot Defense
from vendor documentationManage, Bot and Risk Policies, Allowlist Policy: add our addresses, Save and Deploy.
Fastly, Imperva, Kasada, others
No verified recipe yet. We set this up together with your platform team in a short call. The principle is the same: allow our IP addresses before the bot rules run.
Your own server or rate limiter
Exempt our IP addresses from rate limits and tools like fail2ban. If you block by country, our addresses are in Germany.
Step 3: check again
Run the access check again; every profile must be green. After that we check on every capture. If your protection starts blocking us later, the capture is marked as blocked (never stored as if it were your page) and you get one message with the matching instruction.
If you want us gone
Remove the verification record or delete the project and captures stop at once. You can also block our IP addresses. See also our crawler page.