Documentation · CDN and bot protection
Ottom’s agent identifies itself with a published user agent and reaches your store from a small set of published addresses. To let it through your CDN’s bot protection, add one rule that matches both and skips only the bot checks. These pages give that rule for Cloudflare, Fastly, Akamai, AWS, Azure, Google Cloud and Vercel.
Your CDN answered with a challenge page instead of your store, so the scan could not see a product at all.
A product page came back as a 403, 429 or 503 twice, ten minutes apart. A firewall rule or a rate limit usually explains it.
Pages loaded, but the add to cart request was refused, often by a challenge on the cart endpoint alone.
OttomAgent/. The full string is OttomAgent/1.0 (+https://ottom.io/agent), with Mobile added when a check walks your store at phone size.https://ottom.io/agent/ips.json, also listed on our agent page.Custom rules with Skip, IP lists, Super Bot Fight Mode, and the free plan’s Bot Fight Mode.
Next-Gen WAF lists and request rules, and an ACL for VCL services.
Bot Manager custom bot categories, client lists, and activation.
IP sets, an AND rule with Allow, rule priority, and a Bot Control scope down.
WAF policy custom rules, SocketAddr, priority, and the Bot Manager rule set.
Security policy rules, the rules language, and priority.
Firewall custom rules with Bypass, for stores hosted on Vercel.
Shopify, Wix, Squarespace and other hosted platforms run their own CDN and bot protection in front of every store, and a merchant cannot add rules to it. If a scan of a store on one of them reports bot protection, the block is the platform’s, not yours. Tell us from the report and we look at that scan. If you put your own CDN in front of a hosted platform, the guide for that CDN still applies to the part you control.
The addresses change rarely. When they do, https://ottom.io/agent/ips.json and our agent page change on the same deploy, because both read the same setting. Check the file when you review your firewall, or have a scheduled job read it and update your list. The file follows the shape Google and other crawler operators use for their own address lists (a creationTime and a list of prefixes), so a script that already reads one of those reads ours. A store under an Enterprise Plus contract with a dedicated address can allow that address instead: it is the one your contract names.
No. A blocked scan is reported as a block, never as a pass or a stall it did not see. It is worth knowing that the same rule turns away every agent that identifies itself honestly, which is the kind you would probably want to admit.
Not by the user agent alone, which is why every rule here also matches the address. A request with our user agent from any other address is not us, and the rule leaves it to your bot protection as before.
No. The rule matches our user agent from our addresses and nothing else. Whether to admit other agents is a separate decision, made in your provider’s bot settings.
It should not, and the guides avoid it. They skip bot detection, challenges and rate limits, which are what turn an honest agent away, and keep the rules that inspect a request for attacks wherever the provider lets the two be separated.
No more than our own limits allow. Any one store gets a small number of agent journeys and retrieval checks a day, counted across everyone who asks. The limits page has the numbers.
Everything our agent sends, and how to opt your store out instead: how our agents identify themselves.