MikeL

Posted on Sep 8 Originally published at detectzestack.com

Find Companies Using Akamai Bot Manager (API Guide)

#techstack #webdev #api

A list of companies running Akamai Bot Manager is one of the better-qualified prospect lists you can build from public signals. Bot Manager is not a starter product. It is a paid module bolted onto an Akamai delivery contract, and organizations buy it because scraping, credential stuffing, or inventory hoarding is actively costing them money. Every domain on that list has a security budget, an incident that justified the spend, and a team that already thinks about automated traffic.

The good news for anyone building the list is that Bot Manager is loud. It writes its own session cookies on the way out, which means a single unauthenticated HTTP request reveals it. This guide covers what the module is, the exact cookie names that fingerprint it, the Akamai edge signals underneath, how to check one domain by hand, how to check hundreds through the DetectZeStack API, and what to do when the bot protection blocks the scan itself. Every response below came from a live scan run while writing this post.

Why Build a List of Companies Using Akamai Bot Manager

Three groups get different value from the same list.

Sales and partnerships. Bot Manager sits alongside fraud tooling, identity verification, inventory protection, and API security. If you sell into any of those categories, an Akamai Bot Manager deployment tells you the buyer has already been through a procurement cycle for exactly this problem. That is a warmer starting point than firmographics, because it is evidence of behavior rather than a guess from headcount and industry code.

Competitive intelligence. If you sell bot mitigation, the list is your displacement target. If you sell something adjacent, it tells you which accounts are already committed to the Akamai edge, which shapes how you position an integration.

Engineering and data teams. If you scrape, crawl, or run automated integration tests against third-party sites, knowing in advance which targets run Bot Manager changes your architecture. The right response is usually to seek an official API or a data partnership rather than to spend engineering time on a fight you are not meant to win.

What Akamai Bot Manager Is and Where It Sits in the Stack

Bot Manager Is a Module on the Akamai Edge, Not a Separate Vendor

Akamai’s core business is content delivery: a global edge network that terminates TLS close to the user, caches what it can, and forwards the rest to the origin. Bot Manager is a policy layer that runs on that same edge. When it is enabled on a property, every request is scored before it reaches the origin, and the edge decides whether to serve, challenge, delay, or deny it.

Two consequences follow, and both matter for detection. First, Bot Manager can only exist on a domain that already goes through Akamai, so a Bot Manager hit is also an Akamai hit. Second, the module maintains per-session state to do its scoring, and that state travels in cookies. Those cookies are the fingerprint.

The same architecture applies to Akamai’s other security add-ons. Akamai Web Application Protector, the WAF and DDoS module, is a separate product on the same edge with its own signals, and the two frequently ship together on the same property.

The Signals That Reveal Akamai Bot Manager

The Bot Manager Cookies: ak_bmsc, bm_sz, and bm_sv

DetectZeStack fingerprints Akamai Bot Manager on three Set-Cookie names, and any one of them is enough:

Cookie	What it carries
bm_sz	The session identifier the bot scoring engine keys on
ak_bmsc	The Bot Manager session context for the visitor
bm_sv	Set by the Bot Manager verification flow

Akamai edge responses often carry more than these three. During testing, www.lowes.com and www.delta.com both returned _abck and bm_so alongside bm_sz, and several Akamai properties set akavpau_* and akaalb_* cookies. Those are genuine Akamai artifacts, but they are not part of the three-cookie fingerprint, so a domain that sets _abck and nothing else is not reported as Akamai Bot Manager. If you are building your own detector rather than calling an API, decide deliberately whether you want the narrow, high-precision set or the wider, noisier one.

Why the cookie layer is the right layer here: Bot Manager has no dedicated response header and no dedicated hostname. Akamai sells it as a policy on an existing property, so the only thing that changes on the wire when a customer switches it on is the session state the edge starts writing. Anything that reads Set-Cookie sees it on the first request, with no login, no JavaScript execution, and no headless browser.

The Akamai Edge Signals Underneath It

Bot Manager rides on Akamai delivery, and the delivery layer has its own signals across DNS and HTTP. DetectZeStack matches Akamai CNAME suffixes at the DNS layer — .akamaiedge.net, .akamai.net, .edgekey.net, .edgesuite.net, .akamaized.net, and .akamaihd.net — and Akamai-specific response headers at the HTTP layer, principally x-akamai-transformed. Four of the retail and travel domains checked for this post resolve through the same suffix:

$ for d in www.macys.com www.lowes.com www.delta.com www.homedepot.com; do
printf '%-22s %s\n' "$d" "$(dig +short $d CNAME)"
done
www.macys.com          www.macys.com.edgekey.net.
www.lowes.com          wwwlowes.com.edgekey.net.
www.delta.com          www.delta.com.edgekey.net.
www.homedepot.com      www.homedepot.com.edgekey.net.

The Bot Manager fingerprint also carries an implication: Akamai Bot Manager implies Akamai, so Akamai appears under CDN in the response even on a scan where no separate Akamai pattern matched. When both layers fire, the merge deduplicates by technology name and the HTTP entry wins, which is why Akamai usually comes back with source: "http" rather than "dns". One name that is not a fingerprint is worth calling out: Server: AkamaiGHost appears on many Akamai error and challenge responses, but it is not in the pattern database, so do not expect it to produce a detection on its own. The full DNS and header method for the delivery layer is covered in find companies using Akamai.

Check One Domain by Hand With curl

For a single domain, one request answers the question. Use -D - to dump headers and -o /dev/null to discard the body, then filter for the three cookie names:

$ curl -s -D - -o /dev/null "https://www.delta.com" \
| grep -oiE "set-cookie: (ak_bmsc|bm_sz|bm_sv)" 
set-cookie: bm_sz

Any output at all is a positive. To see the surrounding Akamai context in the same call, widen the filter to the delivery headers:

$ curl -s -D - -o /dev/null "https://www.lowes.com" \
| grep -iE "^(x-akamai-transformed|server):"
x-akamai-transformed: 9 367 0 pmb=mRUM,2

This works, and it stops working the moment your list has more than a couple of dozen rows. You are managing timeouts, redirect chains, sites that reject a bare HEAD, and the parsing of everything else on the page that decides whether the lead is worth a call. That last part is the real limitation: grep gives you one bit, and prospecting needs the whole stack.

Detect Akamai Bot Manager With the DetectZeStack API

The /demo Endpoint, No API Key Required

The public /demo endpoint takes a url query parameter, needs no API key, is limited to 20 requests per hour per IP, and returns exactly the same JSON shape as the authenticated endpoint. Here is the live response for www.lowes.com, trimmed to the entries that matter for this post:

$ curl -s "https://detectzestack.com/demo?url=www.lowes.com" | jq '.'
{
"url": "https://www.lowes.com",
"domain": "www.lowes.com",
"technologies": [
{
"name": "Akamai",
"categories": ["CDN"],
"confidence": 100,
"description": "Akamai is global content delivery network (CDN) services provider for media and software delivery, and cloud security solutions.",
"website": "https://akamai.com",
"icon": "Akamai.svg",
"source": "http"
},
{
"name": "Akamai Bot Manager",
"categories": ["Security"],
"confidence": 100,
"description": "Akamai Bot Manager detect bots using device fingerprinting bot signatures.",
"website": "https://www.akamai.com/us/en/products/security/bot-manager.jsp",
"icon": "Akamai.svg",
"source": "http"
},
{
"name": "Adobe Experience Manager",
"categories": ["CMS"],
"confidence": 100,
"source": "http"
},
{
"name": "React",
"categories": ["JavaScript frameworks"],
"confidence": 100,
"source": "http"
},
{
"name": "Sectigo",
"categories": ["SSL/TLS certificate authority"],
"confidence": 70,
"source": "tls"
}
],
"categories": {
"CDN": ["Akamai"],
"CMS": ["Adobe Experience Manager"],
"JavaScript frameworks": ["React"],
"SSL/TLS certificate authority": ["Sectigo"],
"Security": ["HSTS", "Blue Triangle", "Akamai Bot Manager"]
},
"meta": {
"status_code": 200,
"tech_count": 13,
"scan_depth": "full"
},
"cached": false,
"response_ms": 2900
}

Read the categories object rather than scanning the array: categories.Security is where Bot Manager lands, and it is a list, so test for membership rather than equality. The full scan returned 13 technologies including Adobe Experience Manager as the CMS and React on the front end — the context that turns a detection into a qualified lead. The description, website, and icon fields are trimmed on three entries above to keep the listing short; the API always returns them when the fingerprint database has them.

Single Domain: GET /analyze With Your API Key

For production use, call /analyze with your key. The response shape is identical to /demo, so the same jq filters work on both. This pulls out just the fields a prospecting pipeline needs:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=www.delta.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
| jq '{domain, security: .categories.Security, cdn: .categories.CDN,
tech_count: .meta.tech_count, depth: .meta.scan_depth, cached, response_ms}'
{
"domain": "www.delta.com",
"security": ["Akamai Bot Manager", "HSTS"],
"cdn": ["Amazon S3", "Akamai"],
"tech_count": 7,
"depth": "full",
"cached": false,
"response_ms": 388
}

Delta is a good illustration of why the CDN field is a list. Amazon S3 appears next to Akamai because assets load from an S3 bucket while the HTML is served through the Akamai edge, and Amazon Web Services shows up separately under PaaS in the full response. A stack is rarely one vendor.

Two fields to read on every result. meta.scan_depth is "full" when headers and body were fetched and "partial" when only DNS resolved; a partial scan never saw a Set-Cookie header, so the absence of Akamai Bot Manager on a partial scan means unknown, not no. cached tells you whether the result came from DetectZeStack’s cache, and response_ms is the wall-clock time for the call.

Yes or No: GET /check?url=...&tech=Akamai%20Bot%20Manager

When a boolean is all you need, /check returns a much smaller object. The technology name is matched case-insensitively and must be URL-encoded because it contains spaces:

$ curl -s "https://detectzestack.p.rapidapi.com/check?url=www.delta.com&tech=Akamai%20Bot%20Manager" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"domain": "www.delta.com",
"technology": "Akamai Bot Manager",
"detected": true,
"confidence": 100,
"version": "",
"categories": ["Security"],
"response_ms": 0,
"cached": true
}

The technology field echoes the canonical name from the database on a match, so tech=akamai%20bot%20manager in lowercase comes back as "Akamai Bot Manager". A miss returns "detected": false with confidence 0 and an empty categories array. The response_ms: 0 above is a cache hit from the /analyze call a moment earlier.

When the Bot Manager Blocks the Scan: Reading a 403 Result

Bot Manager sometimes decides a scanner is a bot, which is the entire point of the product. A challenged request comes back as HTTP 403 with a Server: AkamaiGHost header and a challenge page instead of the real site. That is not a failed scan — the block is itself a strong signal. Here is what www.macys.com returned:

$ curl -s "https://detectzestack.com/demo?url=www.macys.com" \
| jq '{categories, meta}'
{
"categories": {
"CDN": ["Akamai"],
"SSL/TLS certificate authority": ["Sectigo"],
"Security": ["Akamai Bot Manager"]
},
"meta": {
"status_code": 403,
"tech_count": 3,
"scan_depth": "full"
}
}

The challenge response still carried the Bot Manager cookies, so both Akamai entries were reported. What is missing is everything else: no CMS, no framework, no analytics, because no application HTML was ever served. Handle this pattern explicitly in a prospecting pipeline. A status_code of 403 with a tech_count in the low single digits and Akamai Bot Manager present is a high-conviction lead with a thin profile, not a dead row. Sort those into their own bucket and enrich them from a different source rather than discarding them.

Screen a Prospect List at Scale With POST /analyze/batch

POST /analyze/batch accepts up to 10 URLs per request and scans them concurrently. Each item in results carries either a result object in the single-domain shape or an error string. The script below reads domains.txt, one domain per line, sends batches of 10, and writes one CSV row per domain: whether Bot Manager was found, the full security list, the CDN list, the HTTP status, and the technology count. Partial scans go to a retry file instead of being recorded as negatives, and blocked domains go to their own file:

#!/usr/bin/env bash
# find-akamai-bot-manager.sh - build a Bot Manager prospect list
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,bot_manager,security,cdn,status,tech_count" > akamai_bm.csv
: > akamai_bm_retry.txt
: > akamai_bm_blocked.txt

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
resp=$(curl -s -X POST "https://$HOST/analyze/batch" \
-H "X-RapidAPI-Key: $KEY" \
-H "X-RapidAPI-Host: $HOST" \
-H "Content-Type: application/json" \
-d "$urls")

# One row per fully scanned domain
echo "$resp" | jq -r '.results[]
| select(.result != null and .result.meta.scan_depth == "full")
| .result as $r
| [
$r.domain,
((($r.categories.Security // []) | index("Akamai Bot Manager")) != null),
(($r.categories.Security // []) | join(";")),
(($r.categories.CDN // []) | join(";")),
($r.meta.status_code | tostring),
($r.meta.tech_count | tostring)
] | @csv' >> akamai_bm.csv

# Challenged: Bot Manager present but the page never rendered
echo "$resp" | jq -r '.results[]
| select(.result.meta.status_code == 403)
| .result.domain' >> akamai_bm_blocked.txt

# Unknown: DNS only, so no Set-Cookie header was ever seen
echo "$resp" | jq -r '.results[]
| select(.result != null and .result.meta.scan_depth == "partial")
| .result.domain' >> akamai_bm_retry.txt
done

echo "scanned:     $(($(wc -l < akamai_bm.csv) - 1))"
echo "bot manager: $(awk -F, 'NR>1 && $2=="true"' akamai_bm.csv | wc -l)"
echo "challenged:  $(wc -l < akamai_bm_blocked.txt)"
echo "retries:     $(wc -l < akamai_bm_retry.txt)"

A 1,000-domain list is 100 batch calls. Throughput, retry policy, and a production Python version of this loop are covered in how to batch scan 1,000 websites.

Reverse Lookup: Domains Already Known to Run Bot Manager

If you do not have a domain list to start from, GET /lookup works the other way around. It searches the domains DetectZeStack has already scanned and returns the ones where a given technology was recorded:

$ curl -s "https://detectzestack.p.rapidapi.com/lookup?tech=Akamai%20Bot%20Manager&limit=5" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"technology": "Akamai Bot Manager",
"total": 173,
"results": [
{
"domain": "www.ajio.com",
"category": "Security",
"confidence": 100,
"version": "",
"first_seen": "2026-05-15T10:03:40Z",
"last_seen": "2026-09-07T18:01:52Z"
},
{
"domain": "www.ing.com.au",
"category": "Security",
"confidence": 100,
"version": "",
"first_seen": "2026-05-11T03:28:59Z",
"last_seen": "2026-09-07T18:01:45Z"
}
],
"limit": 2,
"offset": 0,
"response_ms": 11
}

Two caveats. total counts only domains that have been scanned at least once, so it is a floor, not a census of the internet — 173 was the count at the time of writing and it grows as the corpus does. And the number of rows you get back is capped by tier: 2 on free, 50 on the $9 plan, 200 on the $29 plan, and 800 on the $79 plan. The response above was taken on a free key, which is why limit came back as 2 rather than the requested 5. The first_seen and last_seen timestamps are the useful part for anyone tracking adoption over time.

Comparing Two Sites’ Edge Security Posture With POST /compare

POST /compare takes 2 to 10 URLs and returns each domain’s full technology list plus a shared array of what they all have in common and a unique array per domain. It is the fastest way to put a prospect next to a competitor. Two US airlines, scanned live:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/compare" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["www.delta.com", "www.jetblue.com"]}' \
| jq '{shared, total_ms,
domains: [.domains[] | {domain, unique}]}'
{
"shared": ["HSTS"],
"total_ms": 2178,
"domains": [
{
"domain": "www.delta.com",
"unique": ["Bootstrap", "DigiCert", "Akamai", "Akamai Bot Manager",
"Amazon S3", "Amazon Web Services"]
},
{
"domain": "www.jetblue.com",
"unique": ["Varnish", "Fastly", "Let's Encrypt", "React"]
}
]
}

Two airlines, two entirely different edges. Delta is on Akamai with Bot Manager active; JetBlue is on Fastly with no bot-management module visible from the outside. If you sell bot mitigation, that contrast is the opening line of an email to one of them. The Fastly signals in that second list are broken down in find companies using Fastly.

Pricing, Rate Limits, and Getting an API Key

The /demo endpoint is the fastest way to confirm the response shape against a domain you already know: no signup, 20 requests per hour per IP, full JSON. For lists, audits, or anything you want to run again next quarter, the free RapidAPI plan includes 100 requests per month with no credit card. Paid plans start at $9 per month for 1,000 requests, and every plan includes header, cookie, DNS, and TLS detection on every scan, so Akamai Bot Manager, the Akamai edge underneath it, and the rest of the stack all come back in the same call.

Conclusion and Next Steps

Akamai Bot Manager is detected from three Set-Cookie names — ak_bmsc, bm_sz, and bm_sv — written by the Akamai edge when the module is active on a property. It lands under the Security category at confidence 100 and pulls Akamai into CDN by implication, and the delivery layer underneath usually confirms it with an edgekey.net CNAME or an x-akamai-transformed header. For one domain, a single curl with a grep on the cookie names answers the question. For a prospect list, /analyze/batch returns the whole stack in structured JSON at 10 domains per call, /lookup works backwards from the technology to the domains, and /compare puts two stacks side by side. The one rule worth writing into the pipeline: a 403 with Bot Manager present is your best lead, not a failed row.

DEV Community