DEV Community: MikeL

Find Companies Using Java: Detection Signals and API

MikeL — Thu, 24 Sep 2026 14:00:28 +0000

Java runs a large share of enterprise web backends: banks, retailers, airlines, telecoms, and most of the big content management platforms. If you sell Java tooling, application security, JVM monitoring, or migration services, a list of companies using Java is a list of prospects. The problem is that Java is not in the page. It runs on the server, and the HTML it produces looks like any other HTML.

This guide covers the signals that do leak out of a Java backend, exactly which of them DetectZeStack matches (and which it does not), and how to turn a domain list into a Java prospect list with a few API calls. The API responses and headers quoted below came from real requests made while writing this post.

Why Finding Companies Using Java Is Harder Than Front-End Tech

Front-end libraries announce themselves. A site that uses jQuery has a <script> tag pointing at a jQuery file, and anyone can read it. A site that uses Java has a JVM somewhere behind its load balancer, and the only trace in the response is whatever the application server, framework, or CMS happens to add to it.

Java Runs on the Server, So Detection Relies on Indirect Signals

Every Java detection is an inference from a side effect: a session cookie the servlet container sets, a header the application server stamps on responses, or a product that is known to be built on Java. That makes Java detection different in two ways. First, the signal is often in the headers, not the HTML. Second, it can disappear without the backend changing at all, because a proxy in front of the application stripped it.

Signals That a Website Runs on Java

These are the signals worth knowing, in rough order of how often you will see them. The table at the end of this section shows which ones DetectZeStack's HTTP scan actually matches.

JSESSIONID Session Cookies

JSESSIONID is the default session cookie name in the Java Servlet specification, so Tomcat, Jetty, WildFly, WebLogic, WebSphere and most other servlet containers use it unless the application renames it. It is the single most common Java signal. You can check for it with one command:

curl -s -o /dev/null -D - https://confluence.atlassian.com | grep -i '^set-cookie: jsessionid'

When we ran it, Atlassian's Confluence site answered with set-cookie: JSESSIONID=AE599AB7...; Path=/; Secure; HttpOnly. Confluence is a Java application, and the cookie gives it away even though the Server header just says AtlassianEdge.

Server and X-Powered-By Headers (Apache Tomcat, Jetty, JBoss/WildFly, Servlet/JSP)

Application servers that are not hidden behind a proxy often identify themselves:

Server: Apache-Coyote/1.1 is Tomcat's HTTP connector.
Server: Jetty(9.4.51.v20230217) is Eclipse Jetty, with a version.
X-Powered-By: Servlet/3.0 JSP/2.2 is added by several Java EE servers and names the spec versions.
X-Powered-By: JBoss-7.1 and X-Powered-By: Undertow/1 come from JBoss and WildFly.
X-Application-Context is a header older Spring Boot versions added by default.

Check them with curl -sI https://example.com and read the server and x-powered-by lines.

URL Patterns (.jsp, .do, .action, ;jsessionid=)

Java web apps have recognizable URL habits. JavaServer Pages end in .jsp. Apache Struts 1 maps actions to .do and Struts 2 to .action. When a servlet container cannot set a cookie, it rewrites links to carry the session in the path, as in /cart;jsessionid=ABC123. These are good hints when you look at a site by hand, but they are weak on their own, because any server can be configured to serve a path ending in .do.

Framework Traces (Spring, Struts, JSF)

Frameworks leave their own marks. JavaServer Faces pages include a hidden form field named javax.faces.ViewState (or jakarta.faces.ViewState in newer versions). Spring shows up through the X-Application-Context header mentioned above. Vaadin apps load a vaadinBootstrap.js script. And a lot of Java reaches the web through products built on it: Adobe Experience Manager, Liferay, Magnolia CMS, Atlassian Confluence and Jira all run on the JVM.

What Doesn't Count as Java: JavaScript Is Unrelated

JavaScript and Java share four letters and nothing else. A site running React, Angular, or jQuery tells you about its front end, not its backend. When you filter scan results, match on the exact name Java in the Programming languages category. A substring match on "java" will also catch JavaScript libraries and JavaScript frameworks and flood your list with false positives.

Which Signals DetectZeStack Matches

DetectZeStack's HTTP detection uses the open-source Wappalyzer fingerprint set. It fetches the page, reads the headers, cookies and HTML, and does not run JavaScript. We ran each signal above through the same fingerprint library the API uses:

Signal	Reported as	Also adds Java?
JSESSIONID cookie	Java	—
Server: Apache-Coyote	Apache Tomcat	Yes
X-Powered-By: Tomcat-9.0.83	Apache Tomcat 9.0.83	Yes
Server: Jetty(9.4.51...)	Jetty 9.4.51	Yes
X-Powered-By: Servlet/3.0 JSP/2.2	Java Servlet 3.0, JavaServer Pages 2.2	Yes
X-Application-Context	Spring	Yes
Adobe Experience Manager paths (/etc.clientlibs/)	Adobe Experience Manager	Yes
X-Powered-By: JBoss-7.1	JBoss Application Server 7.1	No
X-Powered-By: Undertow / Server: WildFly	not detected	No
javax.faces.ViewState hidden field	not detected	No
.jsp / .do links, ;jsessionid= in URLs	not detected	No

Three things stand out. Java is usually reported as an implied technology: when the scan finds Tomcat, Jetty, Spring, GlassFish, Resin, Vaadin, Liferay, Magnolia CMS or Adobe Experience Manager, it adds a Java entry next to it. JBoss is the exception: its fingerprint does not imply Java, so check for JBoss Application Server separately. And the URL-pattern and JSF ViewState signals are manual checks only. JavaServer Faces is still detected when a server sends X-Powered-By: JSF/2.2.

Limits of Detecting Java from the Outside

Reverse Proxies, CDNs, and Stripped Headers Hide the Backend

The best illustration is Tomcat's own website. A scan of tomcat.apache.org returns Apache HTTP Server, HSTS, Let's Encrypt and Varnish, and no Java, because the project site is static pages served by Apache httpd. The server you see is whatever sits at the edge.

The same thing happens on the commercial side, where Java backends almost always sit behind Akamai, Cloudflare, Fastly, or an Nginx reverse proxy. The edge replaces the Server header, and home pages often come from a cache that never sets a session cookie. The data shows it. As of the September 24, 2026 snapshot of DetectZeStack's index, 134 domains had Java recorded. 101 of those got there through Adobe Experience Manager, 2 through Spring, and 1 through Jetty. Apache Tomcat, the most widely deployed Java server, appeared on zero indexed domains, because its Apache-Coyote header rarely survives the trip through a CDN.

Detection can also change between scans. American Airlines' www.aa.com is in the index with Java, but a scan while writing this post returned only Akamai, Akamai Bot Manager and HSTS. Bot protection and cache state change what a scanner receives. Treat a Java hit as strong evidence, and treat a miss as "nothing visible this time."

API Example: Detect Java with DetectZeStack

Start with the public /demo endpoint. It needs no API key and is rate-limited by IP:

curl -s "https://detectzestack.com/demo?url=https://www.homedepot.com" | python3 -m json.tool

Full Stack Scan with GET /analyze

For production use, call /analyze with your RapidAPI key. This is the response for Home Depot, trimmed to the Java-related entries, with the categories map and meta block left intact. We had just scanned the site, so it came back from cache with "cached": true and a response_ms of 0. A fresh scan takes a few seconds:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=https://www.homedepot.com" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com"

{
"url": "https://www.homedepot.com",
"domain": "www.homedepot.com",
"technologies": [
{
"name": "Java",
"categories": ["Programming languages"],
"confidence": 100,
"description": "Java is a class-based, object-oriented programming language that is designed to have as few implementation dependencies as possible.",
"website": "https://java.com",
"icon": "Java.svg",
"cpe": "cpe:2.3:a:oracle:jre:*:*:*:*:*:*:*:*",
"source": "http"
},
{
"name": "Spring",
"categories": ["Web frameworks"],
"confidence": 100,
"website": "https://spring.io/",
"icon": "Spring.png",
"source": "http"
}
],
"categories": {
"CDN": ["Akamai"],
"Caching": ["Varnish"],
"JavaScript frameworks": ["React"],
"Programming languages": ["Java"],
"Reverse proxies": ["Nginx"],
"SSL/TLS certificate authority": ["DigiCert"],
"Security": ["HSTS", "Akamai Bot Manager"],
"Web frameworks": ["Spring"],
"Web servers": ["Nginx"]
},
"meta": { "status_code": 200, "tech_count": 9, "scan_depth": "full" },
"cached": true,
"response_ms": 0
}

How to read it:

Spring was matched from the X-Application-Context header, the only Spring rule in the fingerprint set. Java was added because Spring implies it.
The stack in front of it is Akamai, Varnish, and Nginx. Java is detected here despite the proxies because the Spring header made it through all three.
React sits in JavaScript frameworks. That is the front end, and it is unrelated to the Java entry.
Empty fields are left out. Neither entry has a version, and Spring has no cpe, so those keys are missing. In jq, use .version // "".

Other sites show the other routes to a Java entry. www.cisco.com returns Adobe Experience Manager plus Java. bitbucket.org returns Magnolia CMS plus Java, matched from its x-magnolia-registration header. confluence.atlassian.com returns Java alone, from the JSESSIONID cookie.

Yes/No Check with GET /check?tech=Java

If you only need a yes or no, /check takes a tech parameter and returns a flat object with detected, confidence, version, and categories. The name match is case-insensitive:

curl -s "https://detectzestack.p.rapidapi.com/check?tech=Java&url=https://www.cisco.com" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com"

Because JBoss does not imply Java, run a second check with tech=JBoss Application Server (URL-encoded as JBoss%20Application%20Server) if JBoss shops matter to you.

Scan a Prospect List with POST /analyze/batch

To start from domains already in the index, call /lookup?tech=Java. It returns matching domains with first_seen and last_seen timestamps, and the number of results per page depends on your plan:

curl -s "https://detectzestack.p.rapidapi.com/lookup?tech=Java&limit=50" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
| jq -r '.results[].domain'

To check your own list, send up to 10 URLs per request to /analyze/batch. Each URL counts as one request against your quota. Each item nests its analysis under .result, or carries an error string instead:

curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["https://www.homedepot.com", "https://www.cisco.com", "https://confluence.atlassian.com"]}' \
| jq -c '.results[] | {url: .url, java: ([.result.technologies[]? | select(.name == "Java")] | length > 0)}'

This Python script scans domains.txt in chunks of 10 and writes a CSV that records not just whether Java was found but how, which is what makes the list useful for outreach. "Java via Adobe Experience Manager" and "Java via Spring" are different conversations:

import csv, json, os, urllib.request

KEY = os.environ["RAPIDAPI_KEY"]
URL = "https://detectzestack.p.rapidapi.com/analyze/batch"
JAVA_SOURCES = ["Apache Tomcat", "Jetty", "JBoss Application Server", "GlassFish",
"Spring", "JavaServer Pages", "JavaServer Faces", "Java Servlet",
"Resin", "Vaadin", "Apache Wicket", "Adobe Experience Manager",
"Liferay", "Magnolia CMS", "Atlassian Confluence", "Atlassian Jira"]

domains = [d.strip() for d in open("domains.txt") if d.strip()]
rows = []
for i in range(0, len(domains), 10):
chunk = [d if d.startswith("http") else "https://" + d for d in domains[i:i+10]]
req = urllib.request.Request(URL, data=json.dumps({"urls": chunk}).encode(), headers={
"x-rapidapi-key": KEY,
"x-rapidapi-host": "detectzestack.p.rapidapi.com",
"Content-Type": "application/json",
})
with urllib.request.urlopen(req, timeout=120) as resp:
data = json.load(resp)
for item in data["results"]:
techs = {t["name"]: t for t in (item.get("result") or {}).get("technologies", [])}
via = [n for n in JAVA_SOURCES if n in techs]
if "Java" in techs or via:
rows.append({
"url": item["url"],
"via": "; ".join(via) or "Java only",
"versions": "; ".join(f"{n} {techs[n]['version']}" for n in via if techs[n].get("version")),
"cdn": "; ".join(n for n, t in techs.items() if "CDN" in t.get("categories", [])),
})

with open("java_prospects.csv", "w", newline="") as f:
w = csv.DictWriter(f, fieldnames=["url", "via", "versions", "cdn"])
w.writeheader()
w.writerows(rows)
print(f"{len(rows)} of {len(domains)} domains show a Java signal")

A row labelled Java only has a Java entry with none of the named sources next to it. That is almost always the JSESSIONID cookie, which is the one rule that reports Java directly instead of implying it. For lists in the thousands, see Batch Scan 1,000 Websites for Tech Stack for concurrency, retries, and quota planning.

Compare Java and Non-Java Stacks with POST /compare

/compare takes 2 to 10 URLs and returns each domain's technologies, a unique list per domain, and a top-level shared list. It is a quick way to see whether a competitor set splits between Java and other backends:

curl -s -X POST "https://detectzestack.p.rapidapi.com/compare" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["https://www.homedepot.com", "https://www.lowes.com"]}' \
| jq '{shared: .shared, unique: [.domains[] | {domain, unique}]}'

If Java is in shared, every site you compared showed a Java signal. If it appears in one domain's unique list, only that one did, which may reflect a real difference or just a proxy hiding the other backend.

Using Java Detection for Lead Lists and Security Audits

For sales, the "via" column above is the segmenting field. Adobe Experience Manager sites are large enterprises with a marketing platform budget. Spring and Tomcat hits point to in-house engineering teams running their own Java services. Liferay and Magnolia point to portal and content teams. Pair any of them with the CDN column and you know what sits between the application and its users. For a complete enrichment flow into a CRM, see Build a Lead Enrichment Pipeline with Tech Detection. For comparison with other backends, see Find Companies Using Node.js and Find Companies Using MySQL.

Mapping Detected Versions to CPE Identifiers for Vulnerability Checks

Several Java entries carry a cpe field: Java itself (cpe:2.3:a:oracle:jre), Apache Tomcat, JBoss Application Server, GlassFish, Liferay, Magnolia CMS, and Adobe Experience Manager. DetectZeStack's /vulnerability endpoint looks up CVEs only for technologies that have both a CPE and a detected version. The Java entry never has a version, since no HTTP signal reveals the JRE release, so it is never checked. A Tomcat version from X-Powered-By: Tomcat-9.0.83, or a JBoss or Liferay version from their headers, is checked:

curl -s "https://detectzestack.p.rapidapi.com/vulnerability?url=https://example.com" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com"

In practice, a Java server that publishes its exact version in a header is also a server whose headers were never hardened, which is a finding on its own. Detect Vulnerable Technologies with CPE explains how the CPE matching works and how to read the results.

FAQ

How can I tell if a website runs on Java?

Run curl -sI against the site and look for a JSESSIONID cookie, a Server header starting with Apache-Coyote or Jetty, or an X-Powered-By header naming Servlet, JSP, JSF, or Tomcat. .jsp or .do URLs are further hints.

How do I find a list of companies using Java?

Use /lookup?tech=Java for domains already in the index, then check your own list 10 URLs at a time with POST /analyze/batch, keeping results with an entry named Java.

Is JavaScript the same as Java for tech detection?

No. Java appears under Programming languages. JavaScript libraries and frameworks are front-end code and say nothing about the backend.

Why does a Java website not show Java in the scan?

A CDN or reverse proxy usually replaced the headers and served a cached page with no session cookie. A missing entry means no Java signal was visible, not that the backend is something else.

Conclusion: Get Your Free API Key on RapidAPI

Finding companies using Java comes down to catching the side effects of a Java backend: the JSESSIONID cookie, application server headers, the Spring header, and Java-based products like Adobe Experience Manager and Liferay. DetectZeStack matches those and adds a Java entry whenever one of them implies it. It does not match URL patterns or JSF form fields, and it cannot see through a proxy that strips everything, so treat hits as strong evidence and misses as unknown.

The workflow: one /demo call to see the response shape, /lookup?tech=Java for indexed domains, /analyze/batch for your own list, and the script above to record how each Java signal was found. Each scan also returns the CDN, CMS, and front-end stack from the same request.

Find Companies Using Contentful CMS via API (2026 Guide)

MikeL — Wed, 16 Sep 2026 14:01:10 +0000

Contentful is the headless CMS that shows up underneath a specific kind of company: one that decided its marketing site needed its own front-end team. It is not a starter-plan product and it is not something a freelancer installs on a Friday. Finding the companies running it gives you a segment that has already paid for a content platform, already staffed a front end, and already committed to a build pipeline — which is exactly the profile that buys developer tooling, personalization, search, localization, and migration services.

The catch is that Contentful is genuinely harder to detect than WordPress, and for a structural reason rather than an accidental one. This post covers why, which fingerprints survive a static build, and how to turn those into a list of companies using Contentful through the DetectZeStack API. Every response and every number below was captured on the day this post was written.

Why Companies Using Contentful Are a Distinct Prospect Segment

A CMS detection is usually a weak signal because the population is enormous and undifferentiated. Contentful is the opposite. Adopting it means a team explicitly chose to separate content from presentation, which implies three things you can sell against:

There is a front-end team. Contentful returns JSON, not pages. Somebody has to build the rendering layer, which means an in-house or agency front-end practice exists and has a budget.
There is a build pipeline. Content changes trigger rebuilds or revalidation. That means CI, a hosting platform, preview environments, and all the tooling those drag along.
The site is not the product. Contentful usually sits under a marketing or docs site in front of a real product. The buyer you want is often in growth or marketing engineering, not IT.

Across the DetectZeStack scan corpus as of September 16, 2026, 106 domains carry a Contentful detection. That population skews hard toward B2B SaaS and consumer tech: dovetail.com, temporal.io, www.samsara.com, www.onepeloton.com, www.docusign.com, waymo.com, and www.atlassian.com are all in it. That is a narrow, high-value list — not the long tail you get from a WordPress query.

Why Contentful Is Harder to Detect Than WordPress

Headless means no generator meta tag and no CMS-rendered HTML

WordPress detection is easy because WordPress renders the page. It stamps <meta name="generator" content="WordPress 6.x"> into the head, serves assets from /wp-content/, and exposes /wp-json/. Every one of those is the CMS talking about itself in its own output.

Contentful never renders anything. Its Content Delivery API returns JSON; a framework consumes that JSON and produces the HTML. By the time a page reaches a browser, the markup was generated by Next.js, Gatsby, Nuxt, or a hand-rolled renderer — and those frameworks stamp themselves, not the CMS. There is no generator tag, no admin path, no CMS-owned URL prefix. If you are building a detector from first principles, this is the point where the WordPress playbook stops working. Our broader guide to detecting what CMS a website uses walks through that split in more detail.

The signals that do survive the build: ctfassets.net and the Contentful API host

One thing cannot be compiled away. Images, videos, and downloads uploaded to Contentful are served from Contentful's own asset CDN, and those absolute URLs end up in the rendered HTML because that is the whole point of a hosted asset pipeline. The fingerprint is the asset hostname:

Signal	Where it appears
Image assets	images.ctfassets.net
Video assets	videos.ctfassets.net
Generic assets	assets.ctfassets.net
Downloads	downloads.ctfassets.net
Response header	x-contentful-request-id

You can confirm the asset signal on any site with one line, no API key and no browser:

$ curl -sL https://temporal.io \
| grep -aoE '[a-z0-9.-]+\.(ctfassets\.net|contentful\.com)' \
| sort | uniq -c | sort -rn
230 images.ctfassets.net
2 videos.ctfassets.net

230 image references on a single page. That is not an edge case — it is what a Contentful-backed marketing site looks like from the outside, and it is why the signal is reliable despite being indirect. A lower-volume site still trips it; dovetail.com shows four of each on its homepage.

The header signal, x-contentful-request-id, is a different thing and worth understanding so you do not go looking for it in the wrong place. It is set by Contentful's own API hosts, not by customer websites:

$ curl -sI "https://cdn.contentful.com/spaces/foo/entries" | grep -i contentful
server: Contentful
x-contentful-request-id: 0679d4f1-a3c1-403b-b078-6a0806ae1efb

A customer's marketing site proxies nothing, so that header will not be on its response. It fires when you scan a Contentful API endpoint directly. In practice, essentially every real-world detection comes from the asset hostname.

The asset host has to be in the rendered HTML to count. A site that proxies Contentful images through its own domain — Next.js image optimization pointed at a custom loader, or a Cloudflare Worker rewriting asset URLs — strips the fingerprint entirely. Those sites run Contentful and will come back negative. This is the main false-negative source, and there is no HTTP-layer workaround for it.

The frontend stack sitting in front of Contentful

Because Contentful cannot render, every Contentful detection arrives with a rendering framework attached — and that co-detection is where the qualification value lives. Counting distinct domains across the 106 Contentful sites in the corpus:

Co-detected technology	Domains
Amazon Web Services	54
React	52
Webpack	46
Next.js	32
Cloudflare	28
Vercel	24
Gatsby	15
Netlify	12
Vue.js	6
Nuxt.js	5

Roughly half of Contentful sites in the corpus run React, and Next.js alone covers 32 of 106. Gatsby is still present on 15, which is a meaningful sub-segment in its own right given Gatsby's trajectory — those are modernization conversations waiting to happen. On the hosting side, Vercel and Netlify together account for 36 of the 106, while AWS shows up on 54.

Check One Domain for Contentful Free (GET /demo)

The public /demo endpoint runs the full detector against any URL with no authentication and no signup, rate limited to 20 requests per hour per IP:

$ curl -s "https://detectzestack.com/demo?url=temporal.io" | python3 -m json.tool

The real response, captured September 16, 2026:

{
"url": "https://temporal.io",
"domain": "temporal.io",
"technologies": [
{
"name": "Contentful",
"categories": ["CMS"],
"confidence": 100,
"description": "Contentful is an API-first content management platform to create, manage and publish content on any digital channel.",
"website": "https://www.contentful.com",
"icon": "Contentful.svg",
"source": "http"
},
{
"name": "HSTS",
"categories": ["Security"],
"confidence": 100,
"description": "HTTP Strict Transport Security (HSTS) informs browsers that the site should only be accessed using HTTPS.",
"website": "https://www.rfc-editor.org/rfc/rfc6797#section-6.1",
"source": "http"
},
{
"name": "Let's Encrypt",
"categories": ["SSL/TLS certificate authority"],
"confidence": 70,
"source": "tls"
},
{
"name": "Vercel",
"categories": ["PaaS"],
"confidence": 100,
"description": "Vercel is a cloud platform for static frontends and serverless functions.",
"website": "https://vercel.com",
"icon": "vercel.svg",
"source": "http"
}
],
"categories": {
"CMS": ["Contentful"],
"PaaS": ["Vercel"],
"SSL/TLS certificate authority": ["Let's Encrypt"],
"Security": ["HSTS"]
},
"meta": { "status_code": 200, "tech_count": 4, "scan_depth": "full" },
"cached": false,
"response_ms": 1901
}

Three fields to read carefully. source: "http" means the Contentful match came from the HTML body rather than DNS or TLS — which is why meta.scan_depth must be "full" for a Contentful result to mean anything. A "partial" scan means the HTTP fetch was blocked or timed out and only the DNS and TLS layers ran, so the absence of Contentful in a partial result is unknown, not negative. And cached and response_ms are top-level fields, not part of meta.

API Examples: Detecting Contentful Four Ways

GET /check?tech=Contentful — a yes/no answer with confidence

When you want a boolean rather than the whole stack, /check runs the same scan and returns a compact object. The technology name is matched case-insensitively:

$ curl -s "https://detectzestack.p.rapidapi.com/check?url=dovetail.com&tech=Contentful" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"domain": "dovetail.com",
"technology": "Contentful",
"detected": true,
"confidence": 100,
"version": "",
"categories": ["CMS"],
"response_ms": 4744,
"cached": false
}

confidence: 100 is what an unambiguous hostname fingerprint earns. version is empty and always will be — Contentful is hosted SaaS, so there is no customer-visible release number to report, and the hostname pattern captures no digits. Filter on name or detected, never on version.

GET /lookup?tech=Contentful — domains already known to run Contentful

/lookup is a reverse index over DetectZeStack's prior scans, not a crawl of the open web. Treat it as a way to seed a list rather than to enumerate every Contentful site that exists. Results paginate with limit and offset, clamped per tier: 2 rows on the free tier, 50 on Pro, 200 on Ultra, 800 on Mega.

$ curl -s "https://detectzestack.p.rapidapi.com/lookup?tech=Contentful&limit=50" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"technology": "Contentful",
"total": 106,
"limit": 2,
"offset": 0,
"results": [
{
"domain": "dovetail.com",
"category": "CMS",
"confidence": 100,
"version": "",
"first_seen": "2026-05-11T04:09:35Z",
"last_seen": "2026-09-16T13:02:44Z"
},
{
"domain": "www.onepeloton.com",
"category": "CMS",
"confidence": 100,
"version": "",
"first_seen": "2026-05-27T13:39:21Z",
"last_seen": "2026-09-15T18:02:31Z"
}
],
"response_ms": 11
}

That call was made on a free-tier key, which is why limit comes back as 2 even though the request asked for 50 — the tier ceiling overrides your parameter silently. total is not clamped, so you can always see how large the segment is before deciding whether the tier is worth upgrading.

The first_seen and last_seen pair is the most underused field in the response. dovetail.com first seen in May and last seen today has run Contentful continuously across every scan in between — a stable signal. A wide gap between the two means the detection is stale and worth re-scanning before the domain goes on an outreach list.

POST /analyze/batch — scan up to 10 prospect domains per request

For domains you bring yourself, /analyze/batch takes up to 10 URLs per request and scans them concurrently. Each item in results carries either a result object with the single-domain shape or an error string. This call mixes two Contentful sites with one that is not:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["dovetail.com", "www.samsara.com", "getbootstrap.com"]}' \
| jq '{successful, failed, total_ms,
rows: [.results[] | {url,
contentful: ([.result.technologies[]? | select(.name == "Contentful")] | length > 0),
cms: .result.categories["CMS"],
depth: .result.meta.scan_depth,
count: .result.meta.tech_count}]}'
{
"successful": 3,
"failed": 0,
"total_ms": 3590,
"rows": [
{ "url": "dovetail.com",    "contentful": true,  "cms": ["Contentful"], "depth": "full", "count": 12 },
{ "url": "www.samsara.com", "contentful": true,  "cms": ["Contentful"], "depth": "full", "count": 8  },
{ "url": "getbootstrap.com","contentful": false, "cms": null,           "depth": "full", "count": 11 }
]
}

getbootstrap.com is a deliberate negative: it has no CMS category at all. Note that a null category is not the same as a miss, and a partial scan is not the same as a negative — the filter has to check the exact name and the scan depth together.

POST /compare — diff a Contentful site against a WordPress competitor

/compare takes 2 to 10 URLs and returns what they share and what each one has alone. Running a headless site against a traditional one makes the architectural split obvious in a single response:

$ 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": ["dovetail.com", "techcrunch.com"]}'
{
"shared": ["HSTS"],
"domains": [
{
"domain": "dovetail.com",
"unique": ["Netlify", "Next.js", "Node.js", "Algolia", "Linkedin Ads",
"React", "Webpack", "Amazon CloudFront", "Amazon S3",
"Amazon Web Services", "Contentful"]
},
{
"domain": "techcrunch.com",
"unique": ["Yoast SEO Premium", "reCAPTCHA", "Google Tag Manager",
"Let's Encrypt", "MySQL", "WordPress", "WordPress Block Editor",
"WordPress Site Editor", "WordPress VIP", "Nginx", "PHP",
"Sailthru", "Yoast SEO"]
}
],
"total_ms": 2547
}

One shared technology out of 25. That is the headless split rendered as data: Contentful plus a JavaScript build chain plus a CDN on one side, WordPress plus PHP plus MySQL plus Nginx on the other. If you sell into one of those worlds, this response tells you in one call which conversation you are having.

Building a Contentful Prospect List End to End

A raw list of Contentful domains is a starting point, not a segment. The value comes from what else is in the same response — and because /analyze returns the entire stack in one call, you already have it without a second lookup.

Two real hits from the batch above sort into completely different buckets. dovetail.com comes back with JavaScript frameworks: ["Next.js", "React"], PaaS: ["Amazon Web Services", "Netlify"], Search engines: ["Algolia"], Advertising: ["Linkedin Ads"], and 12 technologies total — a mature Jamstack build with a search vendor and paid acquisition already in place. www.samsara.com comes back with JavaScript frameworks: ["Nuxt.js", "Vue.js"], A/B Testing: ["Intellimize"], CDN: ["Amazon CloudFront"], and 8 technologies — a Vue shop on AWS running personalization, with no search vendor detected.

Same CMS, opposite pitches. If you sell site search, dovetail already bought and samsara has not. If you sell React component libraries, the Vue site is disqualified before anyone writes an email. If you sell experimentation tooling, samsara has already proven it will pay for that category. Filtering Contentful hits on the co-detected framework and vendor set splits the list along exactly the line your product cares about.

Here is the whole thing as a shell pipeline. It reads domains.txt one domain per line, sends batches of 10, writes one CSV row per Contentful hit with the co-detected framework and hosting, and pushes failures and partial scans into a retry file instead of silently counting them as negatives:

#!/usr/bin/env bash
# find-contentful.sh - build a Contentful prospect list from domains.txt
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "requested,resolved,frameworks,hosting,tech_count" > contentful.csv
: > contentful_retry.txt

# 10 URLs per request is 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")

echo "$resp" | jq -r '.results[]
| select(.result != null)
| . as $item
| $item.result as $r
| select([$r.technologies[].name] | index("Contentful"))
| [
$item.url,
$r.domain,
(($r.categories["JavaScript frameworks"] // []) | join(";")),
(($r.categories["PaaS"] // []) | join(";")),
($r.meta.tech_count | tostring)
] | @csv' >> contentful.csv

# Fetch errors and DNS-only scans are unknown, not negative
echo "$resp" | jq -r '.results[]
| select(.error != null or .result.meta.scan_depth == "partial")
| .url' >> contentful_retry.txt

sleep 1
done

echo "Contentful hits: $(($(wc -l < contentful.csv) - 1))"

A 1,000-domain list is 100 batch calls. Throughput, retries, and a Python version of this loop are covered in how to batch scan 1,000 websites. For wiring the resulting rows into a CRM alongside firmographic data, see building a lead enrichment pipeline with tech detection.

Tracking Migrations Onto and Off Contentful

A company mid-replatform is worth more than a company that settled three years ago, and the timing signal is in the change feed. GET /changes?domain=example.com returns technologies added and removed between consecutive scans of a domain, with history depth gated by tier: 7 days on Basic, 30 on Pro, 90 on Ultra, 365 on Mega. GET /history?domain=example.com&include_changes=true gives you the same movement attached to the underlying snapshots.

One honest warning before you build alerting on this. Over the change history for Contentful in the corpus, there are 33 added events and 35 removed events — and they are not 68 migrations. www.atlassian.com alone accounts for 13 adds and 13 removes, and www.chegg.com for 9 and 9. Those domains are flapping, not replatforming: their homepage sometimes renders with a ctfassets.net asset and sometimes does not, depending on which A/B or personalization variant the scanner happened to receive.

A single removed event is noise. A sustained absence is a migration. Before you treat a Contentful removal as a replatform, require the technology to be missing from several consecutive full scans, and check whether the same domain has flapped before. A domain with a one-directional change and no history of alternating events — monzo.com added it once, bombas.com removed it once — is the shape you actually want to alert on.

If you want this pushed to you rather than polled, tracking website tech changes via API covers the monitoring side, including the alerting patterns that filter out exactly this kind of flapping.

Rate Limits, Caching, and What a Contentful Sweep Costs

Scan results are cached per domain, and a cache hit is what makes a repeat sweep cheap. In the /check response above, cached: false with response_ms: 4744 is a cold fetch of a heavy marketing page; a warm repeat of the same domain returns in single-digit milliseconds. That matters for list hygiene: re-running last quarter's 1,000-domain sweep is dramatically faster than the first pass, because most of those domains are already warm.

Three cost notes worth planning around:

Batch requests are still per-URL against your quota. A 10-URL /analyze/batch call is convenient, not free — budget 1,000 domains as 1,000 requests, not 100.
/lookup is one request regardless of result count. Pulling 200 known Contentful domains on Ultra costs one request. If your goal is a seed list rather than verification of specific accounts, start here.
/demo costs nothing but is capped at 20 requests per hour per IP. Use it to build and debug your jq filter against the exact response shape before you spend a single paid request.

Accuracy Notes and Known Limits

Proxied assets are invisible. Covered above, and it is the single largest false-negative source. A site that rewrites Contentful asset URLs onto its own domain leaves no HTTP-layer trace of the CMS at all.

A partial scan cannot see Contentful. The fingerprint lives in the HTML body. If meta.scan_depth is "partial", only DNS and TLS signals are present and the result is "unknown." Treating it as "no" quietly deletes real prospects from your list, which is why the script above routes partials to a retry file.

Only the URL you give it is scanned. A company whose homepage is a hand-built hero but whose /blog or /resources section is Contentful-backed will come back negative on the apex domain. For Contentful specifically this is a common shape — headless CMSes are frequently adopted section by section. If your list matters, scan two or three representative paths per domain.

Contentful's own marketing site may rate-limit you. A scan of contentful.com returned "status_code": 429 and only two technologies. A non-200 status code in meta is a signal that the body you got was an error page, not the real site — check it before recording the result.

Get Your API Key and Start Finding Contentful Sites

Start with /demo — no key, no signup, and it returns the exact response shape shown above, so you can build your filter before spending a request. When you are ready to scan a list, the free tier on RapidAPI is 100 requests per month with no credit card. Paid plans start at $9/month for 1,000 requests and scale to 50,000. Every tier uses the same endpoints and the same response shape, so the pipeline you write against the free tier runs unchanged when you scale it up.

The same call that finds Contentful also names the rendering framework, the hosting platform, the CDN, the search vendor, the analytics tags, and every other library on the page. One quota, one response, the whole stack.

Find Companies Using Akamai Bot Manager (API Guide)

MikeL — Tue, 08 Sep 2026 14:01:12 +0000

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.

Detect Drupal Website: Manual Checks + API Guide (2026)

MikeL — Mon, 31 Aug 2026 14:00:36 +0000

Drupal is the CMS of governments, universities, media companies, and large enterprises — the segment of the web where WordPress stops and structured content, editorial workflow, and access control begin. That makes "does this site run Drupal?" a question with real money and real risk attached: Drupal shops sell into it, security teams patch it on a deadline, and migration consultants quote against it. The good news is that a default Drupal installation announces itself in several places at once, and even a hardened one usually leaks a signal or two.

This guide covers both approaches: the manual checks you can run against a single site with curl and a view-source, and the DetectZeStack API for confirming Drupal programmatically or sweeping a thousand-domain prospect list. Every code example is copy-pasteable and uses fields that actually exist in the API response.

Why Detect Drupal? Sales, Security, and Migration Use Cases

Three audiences ask this question daily, for different reasons:

Sales and agency teams. If you sell Drupal development, hosting (Acquia-style managed platforms), module work, or support retainers, your addressable market is precisely "organizations currently running Drupal." A verified technographic list beats guessing from industry alone, and because Drupal skews toward government, education, and enterprise, a Drupal hit also tells you something about deal size and procurement style.
Security and asset-inventory teams. Drupal has a history of severe, wormable vulnerabilities — "Drupalgeddon" (SA-CORE-2014-005) and "Drupalgeddon 2" (SA-CORE-2018-002) were both exploited at internet scale within days of disclosure. When the next core advisory drops, the first question is "which of our domains, subsidiaries, and vendors run Drupal?" You want that inventory before the advisory, not after.
Migration and replatforming consultants. Drupal 7 reached end of life in January 2025, and a long tail of sites still runs it. Identifying Drupal sites — and ideally the major version — is how you find replatforming prospects and scope the work.

All three need the same answer in code: is this site Drupal, and if so, which major version?

Manual Ways to Detect a Drupal Website

Drupal emits more fingerprints than most CMSes. Here they are in descending order of reliability.

Check the X-Generator Header and Meta Generator Tag

Modern Drupal (8 and later) sends an X-Generator response header on every page by default. One curl -I answers the question:

$ curl -sI https://www.example.gov | grep -iE "x-generator|x-drupal"
x-generator: Drupal 10 (https://www.drupal.org)
x-drupal-cache: HIT

Two signals in one shot:

X-Generator: Drupal 10 (https://www.drupal.org) — the clearest Drupal tell on the web. It names the CMS, states the major version, and links to drupal.org. If you see this, you are done.
X-Drupal-Cache (and on newer sites X-Drupal-Dynamic-Cache) — Drupal's internal page-cache headers, reporting HIT or MISS. These survive on many sites that strip the generator header, because ops teams rely on them for cache debugging.

There is also a stranger, older tell: Drupal's page cache has historically sent Expires: Sun, 19 Nov 1978 05:00:00 GMT — a deliberately ancient date (Drupal founder Dries Buytaert's birthday) used to mark content as always-stale to intermediaries. Seeing 19 November 1978 in an Expires header is a strong Drupal hint all by itself.

The same generator string usually appears in the HTML head as a meta tag, which survives some proxy configurations that strip custom headers:

$ curl -s https://www.example.gov | grep -io '<meta name="generator"[^>]*>'
<meta name="generator" content="Drupal 10 (https://www.drupal.org)">

Look for /sites/default/ Asset Paths and Drupal Settings JSON

When headers and meta tags have been sanitized, the page body still betrays Drupal's very distinctive file layout. Drupal serves uploaded files, theme assets, and aggregated CSS/JS from /sites/default/files/ (or /sites/all/ on older multisite installs), and no other mainstream CMS uses those paths:

$ curl -s https://www.example.gov | grep -o '/sites/\(default\|all\)/[^"]*' | head -5
/sites/default/files/css/css_AbC123.css
/sites/default/files/js/js_XyZ789.js
/sites/default/files/logo.svg

Drupal 8+ also injects its front-end configuration as a JSON blob with an unmistakable attribute:

<script type="application/json" data-drupal-selector="drupal-settings-json">
{"path":{"baseUrl":"\/","currentPath":"node\/1",...},"user":{"uid":0}}
</script>

Anything containing data-drupal-selector, a drupalSettings JSON payload (or the legacy Drupal.settings object on Drupal 7), or a drupal.js script reference is a body-level confirmation. Sites running Drupal's JavaScript also expose a global Drupal object you can check in the browser console.

Probe Known Drupal Paths (CHANGELOG.txt, /user/login, /core/)

A third manual technique is to request paths that exist on Drupal and almost nothing else:

/user/login — Drupal's login route. A themed login form at exactly this path (rather than /wp-login.php or /admin) is characteristic of Drupal.
/core/CHANGELOG.txt and /core/ assets — Drupal 8+ keeps core files under /core/. On poorly hardened sites, CHANGELOG.txt is world-readable and states the exact version. On Drupal 7 the file lived at /CHANGELOG.txt in the web root.
/core/misc/drupal.js — a core JavaScript file at a predictable path; an HTTP 200 here is a strong signal.

$ curl -s -o /dev/null -w "%{http_code}\n" https://www.example.gov/core/misc/drupal.js
200

A caution: well-run Drupal sites block the txt files precisely because they leak the patch level, and probing paths generates 404 noise in the target's logs. Use path probes as a tiebreaker, not an opener — and only against sites you have a legitimate reason to assess.

Why Manual Checks Fail on Hardened or Cached Drupal Sites

Each signal above can be individually suppressed. Security-conscious Drupal shops remove the generator header and meta tag (a one-line change or a common hardening module), a CDN or Varnish layer in front of the origin can strip X-Drupal-Cache and rewrite Expires, and an aggressive edge cache can serve pages where aggregation has rewritten asset URLs. A single curl against the home page then comes back clean even though the site is Drupal to the core.

Reliable detection therefore means checking all the signals — headers, meta tags, HTML body patterns, script paths, and the JavaScript layer — and combining them, which is exactly what you do not want to hand-script across a list of 1,000 domains. That is the job of an API.

Detect Drupal Instantly with the DetectZeStack API

DetectZeStack runs the full fingerprint set in one call: the X-Generator and X-Drupal-Cache headers, the 1978 Expires tell, the meta generator tag, /sites/default/ and /sites/all/ asset paths, drupal.js script references, and the Drupal JavaScript global. Any of them firing returns Drupal in the CMS category — and because Drupal implies PHP, a PHP entry usually rides along in the same response.

curl Example with GET /analyze and the JSON Response

You can smoke-test the response shape right now against the public /demo endpoint, which runs the same detector pipeline with no API key (IP rate-limited):

curl -s "https://detectzestack.com/demo?url=https://www.drupal.org" | python3 -m json.tool

The response is a single JSON object. Trimmed to the relevant entries, a Drupal hit looks like this:

{
"url": "https://www.drupal.org",
"domain": "drupal.org",
"technologies": [
{
"name": "Drupal",
"categories": ["CMS"],
"confidence": 100,
"description": "Drupal is a free and open-source web content management framework.",
"website": "https://www.drupal.org/",
"icon": "Drupal.svg",
"source": "http",
"version": "10",
"cpe": "cpe:2.3:a:drupal:drupal:*:*:*:*:*:*:*:*"
},
{
"name": "PHP",
"categories": ["Programming languages"],
"confidence": 100,
"description": "PHP is a general-purpose scripting language.",
"website": "https://www.php.net",
"icon": "PHP.svg",
"source": "http",
"version": "",
"cpe": "cpe:2.3:a:php:php:*:*:*:*:*:*:*:*"
}
],
"categories": { "CMS": ["Drupal"], "Programming languages": ["PHP"] },
"meta": { "status_code": 200, "tech_count": 12, "scan_depth": "full" },
"cached": false,
"response_ms": 1764
}

A few fields worth understanding before you build on them:

version — populated from the generator signal, so it is typically the major version only ("10"). Drupal deliberately omits the minor and patch level from its generator string, and a site that strips the generator entirely returns an empty string here. Empty means "version not externally visible," not "not Drupal."
cpe — the CPE identifier security teams map to vulnerability databases. See CPE identifiers explained for turning this into CVE matches.
source — where the signal came from; "http" for Drupal, since the fingerprints live in the response headers and body.
response_ms and cached — top-level fields (not inside meta) reporting scan duration and cache status. The meta object carries only status_code, tech_count, and scan_depth.

For production, sign up on RapidAPI and call /analyze with your key — same shape, no demo rate limit:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=https://www.drupal.org" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
| jq '.technologies[] | select(.name == "Drupal")'

If Drupal is present, that pipe prints exactly the matching object; if not, jq prints nothing and exits cleanly — easy to wire into a shell filter. When Drupal is the only technology you care about, the /check endpoint answers the yes/no question directly with a ?tech= parameter (case-insensitive), so you skip the client-side filtering entirely.

Checking Drupal Across 1,000 Domains with POST /analyze/batch

For lists, POST /analyze/batch scans up to 10 URLs concurrently per call. A 1,000-domain sweep is therefore 100 batch calls — each URL still counts against your quota, but the concurrency and error handling are the API's problem instead of yours:

curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["www.drupal.org", "www.example.com", "example.gov"]}'

The response wraps one full /analyze result per URL, plus per-item errors so one dead domain does not sink the batch:

{
"results": [
{ "url": "www.drupal.org", "result": { "...full /analyze response..." : "" } },
{ "url": "bad-domain.example", "error": "failed to fetch URL" }
],
"total_ms": 4210,
"successful": 2,
"failed": 1
}

Chunking a file of domains into batches of 10 and extracting the Drupal hits is a few lines of shell:

split -l 10 domains.txt chunk_
for f in chunk_*; do
urls=$(jq -R -s 'split("\n") | map(select(length > 0)) | {urls: .}' "$f")
curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d "$urls" \
| jq -r '.results[] | select(.result.technologies[]?.name == "Drupal") | .url'
done

That prints every Drupal domain in the list, one per line — a prospect list or a patch-day inventory, depending on which hat you are wearing. For throughput, quota math, and connection-reuse patterns at larger scale, see Batch Scan 1,000 Websites for Tech Stack.

Drupal Detection Signals Explained (Headers, HTML, DNS)

For reference, here is the full signal set the detector evaluates, with rough reliability:

Signal	Where	Reliability
X-Generator: Drupal 10 (...)	HTTP header	Definitive; includes major version
X-Drupal-Cache / X-Drupal-Dynamic-Cache	HTTP header	Definitive when present
Expires: 19 Nov 1978	HTTP header	Strong; Drupal's trademark stale date
	HTML head	Definitive; includes major version
/sites/default/ or /sites/all/ asset paths	HTML body	Strong; unique file layout
drupal.js script reference	HTML body	Strong
Drupal JavaScript global	JS runtime	Strong

Note what is not on the list: DNS. Drupal is application code, so DNS-layer detection cannot name it directly — but DNS still adds context. Managed Drupal platforms sit behind recognizable CDN and hosting infrastructure, so the same /analyze call that confirms Drupal from HTTP signals also reports the CDN and hosting layer from DNS, giving you "Drupal on a managed platform" versus "Drupal on a bare VPS" in one response. That distinction matters for both sales (budget signal) and security (who applies the patches).

Comparing Two Sites' Stacks with POST /compare

A common follow-up: you know one target runs Drupal and want to see how a competitor's stack differs, or check which of two university sites carries more legacy. POST /compare takes 2–10 URLs and returns each site's technologies plus the shared and unique sets:

curl -s -X POST "https://detectzestack.p.rapidapi.com/compare" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["www.drupal.org", "wordpress.org"]}'

The response groups the delta for you:

{
"domains": [
{
"url": "www.drupal.org",
"domain": "drupal.org",
"technologies": [ { "name": "Drupal", "categories": ["CMS"], "confidence": 100, "...": "" } ],
"unique": ["Drupal"]
},
{
"url": "wordpress.org",
"domain": "wordpress.org",
"technologies": [ { "name": "WordPress", "categories": ["CMS"], "confidence": 100, "...": "" } ],
"unique": ["WordPress"]
}
],
"shared": ["PHP", "MySQL"],
"total_ms": 3892
}

The unique array on each domain and the top-level shared array answer the "what does one run that the other does not" question without any client-side set math. For an agency pitching a Drupal-to-anything migration, one /compare of the prospect against a reference build is a slide in your deck.

Get Your API Key and Start Detecting

Everything above the batch section works with zero setup via the /demo endpoint. For real volume, get a key on RapidAPI — the free tier includes 100 requests per month, no credit card, and every endpoint shown here: /analyze, /check, /analyze/batch, and /compare. Paid tiers scale from 1,000 to 50,000 requests per month, and the same key also unlocks certificate checks, historical snapshots, and tech-change tracking for the Drupal sites you monitor.

Patch-day tip: the Drupal entry's cpe field is the bridge from "we detected Drupal" to "which advisories apply." Store the CPE alongside the domain when you scan, and the next core security release becomes a lookup instead of a fire drill.

Conclusion

Detecting Drupal on a single site is usually one command: curl -sI and look for X-Generator: Drupal, X-Drupal-Cache, or the 1978 Expires date. When headers are stripped, the meta generator tag, /sites/default/ asset paths, the drupalSettings JSON blob, and predictable core paths like /core/misc/drupal.js fill the gap. No other CMS shares this exact fingerprint set.

Detecting it across a portfolio is one API call per site — /analyze for the full stack, /check for the yes/no, /analyze/batch for lists, and /compare for head-to-head deltas — each returning Drupal in the CMS category with the major version when the site exposes it and a CPE for security work. The same response hands you the rest of the stack for free: PHP, database, CDN, analytics, all in one quota-counted request.

Find Companies Using Mailchimp: API Guide (2026)

MikeL — Sat, 01 Aug 2026 14:01:24 +0000

Mailchimp is where companies start doing email marketing. That makes "uses Mailchimp" one of the most versatile technographic filters there is: depending on what you sell, the same signal marks a warm prospect for your agency, a graduation candidate for your fancier ESP, or a churn risk for your retention team. This guide shows how Mailchimp is detected from the outside and how to turn that detection into a working prospect list with the DetectZeStack API. Every response shape below comes from the live API, and the worked example is a real site.

Why Find Companies Using Mailchimp?

Sales Prospecting for Email Marketing Tools and Agencies

A company running Mailchimp has told you three things without saying a word. They have an audience worth emailing. They have decided email marketing is worth doing. And they picked the entry-level generalist to do it with, which usually means no dedicated email team and a marketing operation still small enough for one platform to cover.

If you run an email marketing agency, that is your ideal client: someone already sold on the channel who lacks the hands to run it well. If you sell templates, deliverability audits, list-cleaning services, landing page builders, or CRM tooling that integrates with Mailchimp, the filter hands you an audience that has pre-qualified itself on budget and intent.

Competitive Intelligence for ESP Vendors

For anyone selling a competing email platform, Mailchimp sites are the displacement list. Mailchimp's pricing scales with contact count, and its ecommerce automation is shallower than specialist tools, so growing companies routinely outgrow it. A Mailchimp signup form on a store that also runs an ecommerce platform and an A/B testing tool is a store that has probably outgrown its ESP already: exactly the account a Klaviyo-style vendor wants to reach first, before the migration decision gets made. The detection tells you where the accounts are; the surrounding stack tells you which ones are ripe.

How Mailchimp Shows Up on a Website

Mailchimp touches a website in two places: the code the site embeds to collect subscribers and track visitors, and the DNS records the domain publishes to send authenticated email. Both are externally visible, and they fail independently, which is why checking both catches companies a single-signal check would miss.

Signup Form Embeds and chimpstatic/list-manage Scripts

The classic integration is the embedded signup form. Mailchimp generates a block of HTML the site owner pastes in, and its markup is unmistakable: a form with the mc-embedded-subscribe-form identifier that posts to the site's list-manage.com subdomain, usually accompanied by a stylesheet from cdn-images.mailchimp.com and the mc-validate.js validation script:

<!-- Begin Mailchimp Signup Form -->
<link href="//cdn-images.mailchimp.com/embedcode/classic-061523.css"
rel="stylesheet" type="text/css">
<form action="https://example.us1.list-manage.com/subscribe/post?u=...&amp;id=..."
method="post" id="mc-embedded-subscribe-form"
name="mc-embedded-subscribe-form">
...
</form>

The second common integration is the connected-site script, which Mailchimp uses for pop-up forms and visitor tracking. It loads from Mailchimp's chimpstatic.com asset domain as an mcjs-connected bundle. DetectZeStack keys on all of these signals: the chimpstatic.com/mcjs-connected script source, the cdn-images.mailchimp.com stylesheet, the mc-validate.js script, and the signup form markup itself. There is no reason for any of them to appear on a page except a live Mailchimp integration, so a match returns a confidence of 100.

On WordPress, the integration is often a plugin rather than pasted embed code, and the API distinguishes the variants:

Detected as	What it means	Signal
MailChimp	Core platform: signup forms, pop-ups, visitor tracking	chimpstatic.com script, embed form markup, mc-validate.js
MailChimp for WordPress	The mc4wp plugin wiring WordPress forms into Mailchimp lists	Assets under /wp-content/plugins/mailchimp-for-wp/
MailChimp for WooCommerce	Store purchase data syncing into Mailchimp automations	Assets under /wp-content/plugins/mailchimp-for-woocommerce/

The plugin detections imply the core platform, so a site running MailChimp for WooCommerce also reports MailChimp itself. The distinction is useful qualification data: a store syncing WooCommerce purchase data into Mailchimp automations is a materially deeper integration, and a materially stickier account, than a blog with a pasted signup form.

Mandrill and DNS-Level Email Signals

A company can send Mailchimp campaigns from a domain whose website carries no Mailchimp code at all: think of a business whose site is a brochure but whose newsletter goes out weekly. Sending leaves traces in DNS instead. Domains that authenticate Mailchimp campaigns add servers.mcsv.net to their SPF record and provision DKIM under the k1 selector. Mandrill, Mailchimp's transactional email arm, uses the mandrill selector.

DetectZeStack's GET /dns endpoint surfaces both. It parses the domain's SPF record into an includes array where an mcsv.net entry is plainly visible, and it probes eight common DKIM selectors in parallel, including k1, mailchimp, and mandrill, reporting which one answered in dkim.selector_tested:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=example.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
| jq '{spf_includes: .spf.includes, dkim: .dkim}'

A servers.mcsv.net include or a DKIM hit on k1 or mandrill is strong evidence the company sends through Mailchimp even when the homepage is silent about it. For prospecting, treat the website signal as primary and the DNS signal as the recall booster that catches senders without on-site forms. There is a full walkthrough of the DNS endpoint in the DNS intelligence guide.

Check a Single Domain with the DetectZeStack API

Before writing any code, confirm the signal by hand. The /demo endpoint needs no API key and no signup:

curl -s "https://detectzestack.com/demo?url=themarginalian.org" \
| jq '.technologies[] | select(.name == "MailChimp")'

Which returns:

{
"name": "MailChimp",
"categories": [
"Marketing automation",
"Email"
],
"confidence": 100,
"description": "Mailchimp is a marketing automation platform and email marketing service.",
"website": "https://mailchimp.com",
"icon": "mailchimp.svg",
"source": "http"
}

Note the capital C. The canonical name in the fingerprint database is MailChimp, not Mailchimp, and the technologies array uses the canonical spelling. Your jq filters and code must match it exactly or they will silently match nothing. The tech parameter on /check is case insensitive on input, so tech=mailchimp works there; the response echoes back MailChimp.

curl Example — GET /analyze

The demo endpoint is rate limited and meant for spot checks. For real volume, get a free API key from RapidAPI and use the authenticated /analyze endpoint, which returns the full stack:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=themarginalian.org" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

{
"url": "https://themarginalian.org",
"domain": "themarginalian.org",
"technologies": [
{ "name": "MailChimp",  "categories": ["Marketing automation", "Email"], "confidence": 100, "source": "http" },
{ "name": "WordPress",  "categories": ["CMS", "Blogs"],                  "confidence": 100, "source": "http" },
{ "name": "WordPress Super Cache", "categories": ["Caching"],            "confidence": 100, "source": "http" },
{ "name": "Cloudflare", "categories": ["CDN"],                           "confidence": 100, "source": "http" },
{ "name": "PHP",        "categories": ["Programming languages"],         "confidence": 100, "source": "http" },
{ "name": "MySQL",      "categories": ["Databases"],                     "confidence": 100, "source": "http" }
],
"categories": {
"Marketing automation": ["MailChimp"],
"Email": ["MailChimp"],
"CMS": ["WordPress"],
"CDN": ["Cloudflare"]
},
"meta": { "status_code": 200, "tech_count": 11, "scan_depth": "full" },
"cached": false,
"response_ms": 1204
}

Reading the Response: technologies, categories, confidence

Three parts of the response do the prospecting work. The technologies array is the evidence: each entry carries the canonical name, its categories, a confidence score, and a source telling you whether the detection came from the HTTP response or a DNS or TLS signal. The categories object is the fast filter: it maps category names to the technologies found in them, so checking whether a domain runs any email platform is one lookup on categories["Marketing automation"] rather than a scan of the array. That lookup catches MailChimp, Klaviyo, and HubSpot in a single pass; filtering on the name MailChimp catches Mailchimp specifically. Pick based on whether you are qualifying a category budget or a displacement target.

And meta.status_code is the honesty check. Mailchimp is detected from the HTML a site returns, so if a site answers the scan with a 403 instead of its page, there is nothing to inspect and Mailchimp will be absent even if the site runs it. Treat any non-200 status_code as inconclusive rather than negative, or you will silently drop real Mailchimp users from your list.

Scan Your Whole Prospect List with POST /analyze/batch

Batch is how you work through a list. It accepts up to 10 URLs per request and scans them concurrently:

curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["themarginalian.org", "davidlebovitz.com", "waitbutwhy.com"]}' \
| jq -r '.results[]
| select(.result.technologies[]?.name == "MailChimp")
| .result.domain'

The response wraps one result per URL with a per-item error field, so a single dead domain does not fail the batch, and the jq filter above prints only the domains where MailChimp was found. Each URL in a batch counts as one request against your monthly quota; batching saves round trips and wall-clock time, not quota. For lists past a few hundred domains, the 1,000-site batch scanning guide covers chunking, retries, and rate pacing.

Compare Mailchimp vs Klaviyo Adoption Across Competitors with POST /compare

When the question is not "who uses Mailchimp" but "which ESP does each of these companies use," POST /compare answers it in one call. It scans 2 to 10 domains and splits every detected technology into what is shared across all of them and what is unique to each:

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": ["themarginalian.org", "ridge.com"]}' | jq '{
shared,
esp: [.domains[] | {domain, unique}]
}'

{
"shared": ["Cloudflare"],
"esp": [
{ "domain": "themarginalian.org",
"unique": ["MailChimp", "WordPress", "WordPress Super Cache", "PHP", "MySQL"] },
{ "domain": "ridge.com",
"unique": ["Klaviyo", "Shopify", "Intelligems", "Fondue"] }
]
}

Run this across a competitor set and the ESP split falls out immediately: the domains with MailChimp in their list are on the entry-level generalist, the ones with Klaviyo have graduated to the ecommerce specialist, and the pattern across five or ten competitors tells you where a market segment is in its email maturity. That is a positioning insight you would otherwise pay a technographics vendor for, and here it is one API call.

Building a Lead List Workflow from Detection Results

Putting it together: read domains from a file, scan them in batches of 10, keep the Mailchimp users, and write a CSV your CRM can ingest.

import csv
import requests

API = "https://detectzestack.p.rapidapi.com/analyze/batch"
HEADERS = {
"X-RapidAPI-Key": "YOUR_KEY",
"X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
"Content-Type": "application/json",
}
BATCH_SIZE = 10  # API maximum per request

def scan(domains):
"""Scan up to 10 domains, yielding (domain, tech_names, status_code)."""
resp = requests.post(API, headers=HEADERS, json={"urls": domains}, timeout=60)
resp.raise_for_status()
for item in resp.json()["results"]:
result = item.get("result")
if not result:
print(f"  skipped {item['url']}: {item.get('error', 'no result')}")
continue
names = [t["name"] for t in result.get("technologies", [])]
status = result.get("meta", {}).get("status_code")
yield result["domain"], names, status

def main():
with open("domains.txt") as f:
domains = [line.strip() for line in f if line.strip()]

prospects = []
for i in range(0, len(domains), BATCH_SIZE):
chunk = domains[i:i + BATCH_SIZE]
print(f"Scanning {i + 1}-{i + len(chunk)} of {len(domains)}...")
for domain, techs, status in scan(chunk):
if status != 200:
# No page HTML means no script-based detection is possible.
print(f"  {domain}: status {status}, inconclusive")
continue
if "MailChimp" in techs:
prospects.append({
"domain": domain,
"depth": ("ecommerce-sync"
if "MailChimp for WooCommerce" in techs
else "wordpress-plugin"
if "MailChimp for WordPress" in techs
else "embed"),
"stack": ", ".join(techs),
})
print(f"  {domain}: MailChimp")

with open("mailchimp_prospects.csv", "w", newline="") as f:
writer = csv.DictWriter(f, fieldnames=["domain", "depth", "stack"])
writer.writeheader()
writer.writerows(prospects)

print(f"\n{len(prospects)} Mailchimp sites out of {len(domains)} domains.")

if __name__ == "__main__":
main()

Two details in that script earn their keep. The status != 200 guard keeps inconclusive scans out of your negatives, and the depth column records whether the integration is a pasted embed, the WordPress plugin, or a full WooCommerce purchase-data sync. Depth is the qualification: an embed can be abandoned in an afternoon, while a store syncing order data has automations wired to it and will hold still long enough for a sales cycle. The stack column carries the rest of the scan, which is what turns a generic opener into a specific one; the lead enrichment pipeline guide and tech stack enrichment for sales teams show how to push it into a CRM.

Get Your API Key

Plans are the standard DetectZeStack tiers, and every URL scanned counts as one request:

Plan	Price	Requests / month
Basic	Free	100
Pro	$9	1,000
Ultra	$29	10,000
Mega	$79	50,000

Results are cached for 24 hours by default; a cache hit comes back with "cached": true, so rescanning the same domain twice in a row measures the cache rather than the scanner. The free tier's 100 requests are enough to validate the whole workflow on a real slice of your prospect list before paying anything.

Conclusion

Mailchimp announces itself in embed forms, connected-site scripts, and DNS records, and each of those signals is one API call away. Start with /demo to see a detection on a site you know, use /analyze/batch to sweep your prospect list, /compare to map ESP adoption across a competitor set, and /dns to catch the senders whose websites keep quiet. Filter on the canonical MailChimp name, guard on meta.status_code, and the output is a lead list with the research already attached.

How to Detect Typekit (Adobe Fonts) on Any Website (2026)

MikeL — Fri, 24 Jul 2026 14:01:20 +0000

Typekit has not officially existed since 2018, and yet it is still one of the most-detected font technologies on the web. That is because when Adobe rebranded the service to Adobe Fonts, the serving infrastructure kept its old hostnames: every site using it today still loads a stylesheet from use.typekit.net, exactly as it did a decade ago. Those hostnames are the detection signature, and they are impossible to hide.

This guide covers how to detect Typekit by hand in under a minute, why the manual approach stops working the moment you have a list of domains instead of one, and how to do the same check programmatically with the DetectZeStack API. Every response shown below comes from the live API against a real site.

What Is Typekit (and Why It's Now Adobe Fonts)

Typekit launched in 2009 as a subscription library of licensed web fonts, was acquired by Adobe in 2011, and was folded into Creative Cloud as Adobe Fonts in 2018. The product name changed; the plumbing did not. Web projects are still identified by a short kit ID, stylesheets are still served from use.typekit.net, and the legacy JavaScript loader still lives on use.typekit.com.

That continuity has a practical consequence for anyone doing technology detection: Typekit and Adobe Fonts are the same signal. Fingerprint databases carry both names because both eras of the product left embeds in the wild, and both fingerprints match the same hostnames. Scan a site with a live embed and you will get two results describing one integration. This is expected, and we will see it in a real API response below.

The signal is also worth detecting. Adobe Fonts rides on a paid Creative Cloud subscription, so unlike a free font CDN, its presence tells you the company behind the site pays for typography. If you want to turn that into a prospect list rather than a yes/no check, see how to find companies using Adobe Fonts, which applies this detection to sales prospecting end to end.

Manual Ways to Detect Typekit on a Website

For a single site you already have open in a browser, three manual checks settle the question.

Check for use.typekit.net Script and Stylesheet URLs

View the page source (Ctrl+U in most browsers) and search for typekit. The modern embed is a stylesheet link in the head:

<link rel="stylesheet" href="https://use.typekit.net/abc1def.css">

Older integrations use the JavaScript embed instead: a script served from use.typekit.com plus a load call:

<script src="https://use.typekit.com/abc1def.js"></script>
<script>try{Typekit.load({ async: true });}catch(e){}</script>

Either one is conclusive. No technology other than Adobe's font service loads assets from those hosts, which is why automated detection assigns this signature full confidence.

Look for the Kit ID and wf-loading Body Classes

The short lowercase token in the embed URL, the abc1def above, is the kit ID. Adobe generates one per web project, and it identifies which licensed fonts the page may load. It is visible to anyone, but it is domain-scoped on Adobe's side, so seeing it does not let a third party reuse the fonts.

Sites using the JavaScript embed give you a second, runtime clue. The loader stamps state classes on the html or body element while fonts load: wf-loading while requests are in flight, then wf-active on success or wf-inactive on failure. Open the browser console and check:

document.documentElement.className
// "wf-typekit-active wf-active ..." on a Typekit JS-embed site

Note the limitation: these classes are added by JavaScript at runtime, so they only exist after the page executes its scripts, and only with the JS embed. The stylesheet embed, which is what Adobe generates for new projects, produces no wf-* classes at all. Treat their absence as meaningless and their presence as supporting evidence.

Inspect Network Requests to p.typekit.net

The third check is the network tab. Open developer tools, reload the page, and filter requests by typekit. A site with a live integration shows the kit CSS from use.typekit.net and then the actual font files from p.typekit.net, Adobe's font-serving host. You can do the same from the console without watching the waterfall:

performance.getEntriesByType('resource')
.map(function(r) { return r.name; })
.filter(function(u) { return u.indexOf('typekit') !== -1; });

If that returns URLs, the fonts are not just referenced, they are being served. This distinguishes a live integration from a leftover embed pointing at a deleted kit.

Why Manual Detection Breaks at Scale

All three checks above take under a minute for one site. They stop being viable the moment the question changes from "does this site use Typekit?" to "which of these 500 domains use Typekit?" Manual checking at that scale fails in predictable ways:

It does not batch. Thirty seconds per site is over four hours of tab-switching for 500 domains, with no machine-readable output at the end.
It is inconsistent. A human checker misses the JS embed on one site, forgets the network tab on another, and mistakes a dead kit for a live one on a third. A fingerprint engine applies the same rules to every domain.
It captures nothing else. While you are in the page source looking for one string, the site's CMS, analytics stack, and CDN are sitting in the same HTML unrecorded. An API scan returns all of it in one pass.
It does not repeat. Technology lists go stale. Rescanning a list monthly by hand is not a workflow anyone sustains; rerunning a script is.

The fix is to move the same signatures into an API call.

Detect Typekit With the DetectZeStack API

DetectZeStack detects Typekit server-side from the HTML a site returns: a link tag pointing at use.typekit.net or use.typekit.com, or a script sourced from use.typekit.com. Both patterns resolve at a confidence of 100, and because they sit in the raw HTML, no headless browser is involved.

Try it first with no API key. The /demo endpoint is free and needs no signup; Behance, Adobe's own portfolio network, is a convenient live example:

curl -s "https://detectzestack.com/demo?url=behance.net" \
| jq '.technologies[] | select(.name == "Typekit")'

Which returns:

{
"name": "Typekit",
"categories": [
"Font scripts"
],
"confidence": 100,
"description": "Typekit is an online service which offers a subscription library of fonts.",
"website": "https://typekit.com",
"icon": "Typekit.png",
"source": "http"
}

The source field is http, meaning the detection came from the page HTML. That is the only place Typekit can appear: fonts load from Adobe's domain rather than the customer's, so there is no DNS record or TLS artifact to key on. If a site answers a scan with an error page instead of its real HTML, the embed is invisible and the detection cannot fire, which is why checking meta.status_code matters, covered below.

Single Domain Check With /analyze

The demo endpoint is rate limited and meant for spot checks. For real use, get a free API key from RapidAPI and call /analyze, which returns the full stack:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=behance.net" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

{
"url": "https://www.behance.net/",
"domain": "www.behance.net",
"technologies": [
{ "name": "Adobe Fonts",   "categories": ["Font scripts"],          "confidence": 100, "source": "http" },
{ "name": "Typekit",       "categories": ["Font scripts"],          "confidence": 100, "source": "http" },
{ "name": "Vue.js",        "categories": ["JavaScript frameworks"], "confidence": 100, "source": "http" },
{ "name": "Varnish",       "categories": ["Caching"],               "confidence": 100, "source": "http" },
{ "name": "HSTS",          "categories": ["Security"],              "confidence": 100, "source": "http" },
{ "name": "HTTP/3",        "categories": ["Miscellaneous"],         "confidence": 100, "source": "http" },
{ "name": "Let's Encrypt", "categories": ["SSL/TLS certificate authority"], "confidence": 70, "source": "tls" }
],
"categories": {
"Font scripts": ["Adobe Fonts", "Typekit"],
"JavaScript frameworks": ["Vue.js"],
"Caching": ["Varnish"],
"Security": ["HSTS"],
"Miscellaneous": ["HTTP/3"],
"SSL/TLS certificate authority": ["Let's Encrypt"]
},
"meta": { "status_code": 200, "tech_count": 7, "scan_depth": "full" },
"cached": false,
"response_ms": 4415
}

There is the double entry promised earlier: Typekit and Adobe Fonts, both under Font scripts, both matched by the same use.typekit.net embed. Filter on either name, or on the category, and do not count them as two technologies. The categories object makes the category route a single key lookup: .categories["Font scripts"] answers "does this site use a hosted font service?" without walking the array.

Check meta.status_code before trusting an absence. Typekit is detected only from the returned HTML. A site that answers your scan with a 403 or 429 shows no embed even if it uses the service, and the scan does not fail loudly; it just comes back thinner. Treat a non-200 status as inconclusive, not as a negative.

Results are cached for 24 hours by default; a repeat scan of the same domain returns "cached": true with a much lower response_ms. That is worth knowing when benchmarking: the second scan measures the cache, not the scanner.

Scanning Many Domains With POST /analyze/batch

Batch is how you work through a list. It accepts up to 10 URLs per request and scans them concurrently:

curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["behance.net", "example.com", "stripe.com"]}' \
| jq -r '.results[]
| select(.result.technologies[]?.name == "Typekit")
| .result.domain'

The response wraps one result per URL with a per-item error field, so one unreachable domain does not fail the batch, and the jq filter prints only the domains where Typekit was found. Each URL counts as one request against your monthly quota; batching saves round trips, not quota. For working through lists in the hundreds or thousands, how to batch scan 1,000 websites covers chunking, retries, and rate pacing.

Typekit vs Google Fonts vs Self-Hosted Fonts: Telling Them Apart

Font loading comes in three flavors, and each leaves a different trail:

Approach	Signature	What it implies
Typekit / Adobe Fonts	Stylesheet or script from use.typekit.net / use.typekit.com; fonts from p.typekit.net	Paid Creative Cloud subscription; licensed typefaces; an active design budget
Google Fonts	Stylesheet from fonts.googleapis.com; fonts from fonts.gstatic.com	Free hosted fonts; a typeface choice, but no spend signal
Self-hosted	@font-face rules pointing at the site's own domain; no third-party font hosts	Performance or privacy priorities, or a licensed font served under its own terms

Both hosted services land in the Font scripts category (Google's entry is named Google Font API), so a category filter catches either while a name filter isolates the paid signal. Self-hosted fonts, by design, have no third-party host to fingerprint; their absence from a scan is not a detection failure but the actual answer. The same host-based logic powers detection of other asset CDNs; detecting cdnjs is the same pattern applied to JavaScript libraries, and detecting Google Tag Manager applies it to the tag-management layer of the same pages.

Get Your API Key and Start Detecting

The free plan covers 100 requests per month with no credit card, which is enough to confirm the signal on the sites you care about; paid plans start at $9 for 1,000 requests. Every plan returns the same full response: Typekit alongside the CMS, analytics, CDN, and everything else in the stack, in one call.

Spot-check a site with /demo, no key required.
Get a free key at RapidAPI and move to /analyze.
Feed your domain list through /analyze/batch, 10 URLs at a time.

Conclusion

Typekit is one of the easiest technologies on the web to detect because it cannot be consumed without advertising itself: the embed sits in the HTML, the hostnames never changed through a rebrand, and there is no false-positive path, since nothing else loads assets from Adobe's font hosts. Check one site by searching the source for use.typekit.net; check five hundred with an API call that applies the same signature uniformly and hands you the rest of the stack for free. Just remember the two quirks: the API returns both Typekit and Adobe Fonts for one integration, and a non-200 status_code means inconclusive, not absent.

Find Companies Using imagesLoaded: API Guide (2026)

MikeL — Thu, 16 Jul 2026 14:01:15 +0000

imagesLoaded is a small JavaScript library by David DeSandro that answers one question: have the images inside a container finished loading? That sounds too narrow to be a prospecting signal, and that narrowness is exactly why it is a good one. Nobody adds imagesLoaded on a whim. It appears on sites with image-heavy layouts that break without it, and it almost always arrives as part of a specific, dateable front-end stack: jQuery, a masonry-style grid, a WordPress theme or page builder doing the enqueueing.

This guide shows how imagesLoaded is detected from the outside and how to turn that detection into a prospect list with the DetectZeStack API. The worked example is a live site, and every response shape below comes from the live API.

What Is imagesLoaded and Why Track Sites That Use It

Browsers report an element's dimensions as zero until its images arrive. Any layout that positions items based on their rendered height — a masonry wall, a justified photo grid, an infinite-scroll feed — will compute positions from those zero heights and paint overlapping bricks unless something waits for the images first. imagesLoaded is that something. It watches a container, fires a callback when every image has loaded or errored, and lets the layout engine run against real dimensions.

As a technographic signal, that tells you three things about a site before you ever open it. First, the site is visually driven: portfolios, photography, real estate, media, ecommerce catalogs. Second, its layout is computed in JavaScript rather than in modern CSS, which dates the front end — CSS grid and aspect-ratio have made much of this machinery unnecessary. Third, someone assembled this stack deliberately, usually via a WordPress theme, a page builder, or a hand-rolled gallery, and that assembly is now a maintenance surface.

How imagesLoaded Fits Into a Front-End Stack (Masonry, Isotope, jQuery Galleries)

imagesLoaded rarely travels alone. It is the companion utility for the same author's layout libraries — Masonry, Isotope, Packery, Flickity — and for jQuery gallery and carousel plugins that need to measure images before arranging them. The canonical pattern looks like this:

// wait for images, then lay out the grid
imagesLoaded('.grid', function() {
new Masonry('.grid', { itemSelector: '.grid-item' });
});

The other common delivery vehicle is WordPress itself. WordPress core ships imagesLoaded in wp-includes/js/imagesloaded.min.js, and themes and page-builder plugins enqueue it whenever a masonry block, filterable portfolio, or gallery widget needs it. That is worth knowing because it shapes what a detection means: a large share of imagesLoaded sites are WordPress sites, and the scan that finds the library will usually name the theme's ecosystem — Elementor, Slick, jQuery — in the same response.

Who Buys From Companies Using imagesLoaded

A company running imagesLoaded has an image-heavy site built on a JavaScript-layout stack that is, in 2026, at least one generation old. Two groups sell into exactly that profile.

Agencies and Freelancers Selling Front-End Modernization

imagesLoaded is a proxy for the whole jQuery-era gallery stack. A site loading it as a standalone file is very likely also loading jQuery, a carousel plugin, and a theme's worth of layout scripts — the exact surface an agency pitches to replace with modern CSS, a component framework, or a lighter theme. The signal also implies the site owner cares how the site looks: they picked an image-forward design and paid someone to build it once, which makes "your gallery stack is five years old and costing you Core Web Vitals" a pitch aimed at someone who already values the outcome. Because the detection usually arrives with the CMS and page builder attached, the outreach can be specific: you are not guessing that they run WordPress with Elementor, the scan said so.

SaaS Vendors Replacing Custom Gallery and Layout Code

Every imagesLoaded detection marks a site that solved image loading and layout by hand. That is the displacement target for gallery and portfolio plugins, digital asset management tools, image CDNs and optimization services, and headless media platforms. The pitch writes itself from the stack: a photography studio gluing imagesLoaded to Masonry inside a WordPress theme is maintaining code that a managed gallery product makes obsolete. And because imagesLoaded correlates with pages that ship many large images, image-optimization vendors get a second angle — these are precisely the sites where LCP improvements are visible to the owner.

How DetectZeStack Detects imagesLoaded

DetectZeStack analyzes the HTML a server returns; it does not execute JavaScript. For imagesLoaded that is enough, because the sites worth finding load it as a named file the scanner can see.

Script Signatures and CDN Fingerprints

The fingerprint keys on the script source. A script tag whose src ends in imagesloaded.js or imagesloaded.min.js resolves the site to imagesLoaded with a confidence of 100, whether the file is served from the site's own origin, from wp-includes/js/, or from a public CDN. The signature also captures the version from a ?v= or ?ver= query string when one is present:

<script src="/wp-content/plugins/.../imagesloaded.min.js?ver=3.0.0"></script>

That ?ver= pattern is how WordPress enqueues every bundled script, which is why imagesLoaded detections so often come with a version number attached and a WordPress detection in the same scan. The version matters for qualification: it is the version of the library the theme shipped, and an old one is a direct measure of how long the front end has gone untouched.

The blind spot to know about: a site that compiles imagesLoaded into a webpack or similar bundle never exposes the filename, so no external scanner can see it — the library's own documentation site bundles its assets and scans clean. In practice this filters your list in a useful direction: script-source detection surfaces exactly the sites loading it the old way, as a standalone file, which are the modernization prospects anyway.

API Example: Check a Single Domain for imagesLoaded

Confirm the signal by hand first. The /demo endpoint needs no API key and no signup. Here it is against wpastra.com, the site of the Astra WordPress theme:

curl -s "https://detectzestack.com/demo?url=wpastra.com" \
| jq '.technologies[] | select(.name == "imagesLoaded")'

Which returns:

{
"name": "imagesLoaded",
"version": "3.0.0",
"categories": [
"JavaScript libraries"
],
"confidence": 100,
"description": "jQuery plugin for seeing if the images are loaded.",
"website": "https://imagesloaded.desandro.com/",
"source": "http"
}

Three fields matter. confidence is 100 because the script source matched exactly. version is 3.0.0, captured from the ?ver= query string on the enqueue. source is http, meaning the detection came from the HTML response rather than a DNS or TLS signal. The same scan returned the rest of the story: WordPress, Elementor, Slick, jQuery, and jQuery Migrate — the full image-heavy WordPress stack this article has been describing, in one call.

For real volume, get a free API key from RapidAPI and use the authenticated endpoints. When you only need a yes or no, /check returns one directly:

curl -s "https://detectzestack.p.rapidapi.com/check?url=wpastra.com&tech=imagesLoaded" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

{
"domain": "wpastra.com",
"technology": "imagesLoaded",
"detected": true,
"confidence": 100,
"version": "3.0.0",
"categories": ["JavaScript libraries"],
"response_ms": 431,
"cached": false
}

The tech parameter is case insensitive, so tech=imagesloaded works and the response echoes the canonical name imagesLoaded. When the library is absent, detected is false and confidence is 0. When a site loads the file without a version query string, version comes back as an empty string; that is a normal detection, not a partial one.

API Example: Build a List of Companies Using imagesLoaded

Single checks answer "does this domain run it?" and require you to bring the domain. The next two endpoints build lists.

Using /lookup?tech=imagesLoaded with Pagination and Tier Caps

/lookup inverts the question: it returns domains already in DetectZeStack's scan index that were observed running imagesLoaded.

curl -s "https://detectzestack.p.rapidapi.com/lookup?tech=imagesLoaded&limit=50" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

{
"technology": "imagesLoaded",
"total": 42,
"results": [
{
"domain": "wpastra.com",
"category": "JavaScript libraries",
"confidence": 100,
"version": "3.0.0",
"first_seen": "2026-07-14",
"last_seen": "2026-07-14"
}
],
"limit": 50,
"offset": 0,
"response_ms": 18
}

first_seen and last_seen have no equivalent in a live scan: they tell you when the index first observed the library on that domain and when it was last confirmed. Page through results with limit and offset. The rows returned per request are capped by plan, and requesting more than your cap clamps to it rather than erroring:

Plan	Max /lookup rows per request
Basic (free)	2
Pro ($9/mo)	50
Ultra ($29/mo)	200
Mega ($79/mo)	800

/lookup reflects what has already been scanned, so treat it as a warm start rather than a census of the web. For a niche library like imagesLoaded, the stronger play is the other direction: bring your own candidate domains and scan them.

Scaling Up with POST /analyze/batch for Your Own Domain Lists

Batch accepts up to 10 URLs per request and scans them concurrently. Feed it a directory of photography studios, a list of agencies' portfolio clients, or an export from any lead database:

curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["wpastra.com", "thisiscolossal.com", "example.com"]}' \
| jq -r '.results[]
| select(.result.technologies[]?.name == "imagesLoaded")
| .result.domain'

The response wraps one result per URL with a per-item error field, so a single unreachable domain does not fail the batch, and the top level reports total_ms, successful, and failed counts. Each URL in a batch counts as one request against your monthly quota — a 10-URL batch costs 10 requests. Batching saves round trips, not quota.

Turning Detections Into a Prospect List

Putting it together: read domains from a file, scan them in batches of 10, keep the imagesLoaded sites, and record the stack context that makes the outreach specific.

import csv
import requests

API = "https://detectzestack.p.rapidapi.com/analyze/batch"
HEADERS = {
"X-RapidAPI-Key": "YOUR_KEY",
"X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
"Content-Type": "application/json",
}
BATCH_SIZE = 10  # API maximum per request

def scan(domains):
"""Scan up to 10 domains, yielding (domain, technologies, status_code)."""
resp = requests.post(API, headers=HEADERS, json={"urls": domains}, timeout=60)
resp.raise_for_status()
for item in resp.json()["results"]:
result = item.get("result")
if not result:
print(f"  skipped {item['url']}: {item.get('error', 'no result')}")
continue
techs = result.get("technologies", [])
status = result.get("meta", {}).get("status_code")
yield result["domain"], techs, status

def main():
with open("domains.txt") as f:
domains = [line.strip() for line in f if line.strip()]

prospects = []
for i in range(0, len(domains), BATCH_SIZE):
chunk = domains[i:i + BATCH_SIZE]
print(f"Scanning {i + 1}-{i + len(chunk)} of {len(domains)}...")
for domain, techs, status in scan(chunk):
if status != 200:
# The page never loaded, so script tags could not be seen.
print(f"  {domain}: status {status}, inconclusive")
continue
names = {t["name"] for t in techs}
if "imagesLoaded" in names:
il = next(t for t in techs if t["name"] == "imagesLoaded")
prospects.append({
"domain": domain,
"imagesloaded_version": il.get("version", ""),
"wordpress": "yes" if "WordPress" in names else "no",
"jquery": "yes" if "jQuery" in names else "no",
"stack": ", ".join(sorted(names)),
})
print(f"  {domain}: imagesLoaded {il.get('version') or '(no version)'}")

with open("imagesloaded_prospects.csv", "w", newline="") as f:
writer = csv.DictWriter(
f,
fieldnames=["domain", "imagesloaded_version", "wordpress", "jquery", "stack"],
)
writer.writeheader()
writer.writerows(prospects)

print(f"\n{len(prospects)} imagesLoaded sites out of {len(domains)} domains.")

if __name__ == "__main__":
main()

Two details in that script carry most of the value. The status != 200 guard treats blocked or failed fetches as inconclusive instead of negative — a site behind aggressive bot protection returns no HTML, so the library will be absent from results even if the site runs it, and silently dropping those rows corrupts the list. And the script records the version and the surrounding stack, because "you are running imagesLoaded 3.x inside an Elementor theme with jQuery Migrate" is an opener that proves you looked, where "I noticed you have a website" is not.

Results are cached for 24 hours by default. A cache hit comes back with "cached": true, which is worth knowing when you rescan a list: the second pass measures the cache, not the site.

Get Started

imagesLoaded is a narrow library with a broad implication: an image-heavy site whose layout still depends on jQuery-era JavaScript, usually inside a WordPress theme that names itself in the same scan. One API call finds the library, its version, and the entire stack around it — which is the research a modernization pitch or a gallery-SaaS displacement pitch actually needs.

Start with /demo to confirm the signal on a site you know. Move to /check for booleans, /analyze/batch for your own lists, and /lookup for a warm start from the index.

How to Find Companies Using WP Engine (API Guide 2026)

MikeL — Wed, 08 Jul 2026 14:00:55 +0000

WP Engine is the managed WordPress host that companies graduate to when their site becomes revenue-critical. Its plans start well above commodity shared hosting, so “uses WP Engine” is one of the rare technographic signals that encodes budget as well as technology: it tells you the company runs WordPress, cares enough about that site to pay a premium for it, and has already delegated the hosting layer to a vendor.

This guide covers what a WP Engine detection tells you about a company, the exact DNS CNAME and HTTP header signals that reveal the platform, and how to turn a raw domain list into a WP Engine-confirmed lead list with the DetectZeStack API—starting with a single curl command you can run right now, no API key required.

Why Find Companies Using WP Engine?

Technographic data—what technology a company actually runs—often qualifies a prospect better than firmographics alone. A WP Engine detection is a specific, verifiable fact about a company’s infrastructure, and it feeds two distinct workflows.

Sales Prospecting for WordPress Agencies and Plugin Vendors

It confirms WordPress with budget attached. Every WP Engine customer runs WordPress—the platform hosts nothing else—and pays managed-hosting prices to do it. If you sell WordPress plugins, themes, maintenance retainers, performance audits, or agency services, a WP Engine list is a WordPress list pre-filtered for willingness to spend on the site.
It maps the buyer. A company on managed hosting has already decided not to run its own servers. The conversation is with a marketing or web team that owns the site as a business asset, not with an infrastructure team—which changes both the pitch and the pain points: plugin conflicts, page speed, redesigns, content workflows.
It stacks with other filters. WP Engine alone is a solid segment; WP Engine plus a page builder or a marketing tool detection is a sharp one. Because a tech detection API returns the whole stack in one response, intersecting filters costs nothing extra—the same trick our Elementor prospecting guide uses at the plugin layer.

Competitive and Migration Intelligence

Hosting-switch campaigns. If you sell a competing platform or migration services, a WP Engine-confirmed list is your total addressable market, enumerated. Rescanning the same list on a schedule shows who has left the platform—and who just arrived.
Market sizing. Scanning a vertical for managed WordPress adoption shows how seriously that segment treats its web presence, and how the managed-hosting share shifts over time between WP Engine, Kinsta, Pantheon, Flywheel, and the rest—all of which are detectable from the same DNS layer.

How WP Engine Reveals Itself (Detection Signals)

WP Engine shows up in two independent layers: the DNS records that route traffic to the platform, and the HTTP headers its cache tier stamps on every response. A site that hides one layer frequently gives away the other.

Layer	Signal	What It Means
DNS CNAME	*.wpengine.com	The domain points at a classic WP Engine install hostname
DNS CNAME	*.wpenginepowered.com	The newer install hostname pattern (e.g. wp.wpenginepowered.com)
DNS CNAME	*.wpeproxy.com	The domain routes through WP Engine’s proxy network
HTTP header	X-Powered-By: WP Engine	The response was served by the WP Engine platform
HTTP header	WPE-Backend: ...	WP Engine’s cache tier names the backend that produced the response
HTTP header	X-Pass-Why / X-WPE-Loopback-Upstream-Addr	Cache-diagnostic headers unique to WP Engine’s stack

DNS CNAME Records Pointing to *.wpengine.com

Every WP Engine install gets a platform hostname, and custom domains reach it through DNS. The classic pattern is a CNAME to <install>.wpengine.com; newer installs use <install>.wpenginepowered.com, and traffic routed through the platform’s proxy network resolves through *.wpeproxy.com hostnames. A single dig shows it:

$ dig www.example.com CNAME +short
examplesite.wpengine.com.

$ dig www.another-example.com CNAME +short
wp.wpenginepowered.com.

All three suffixes are unambiguous—no one CNAMEs to a WP Engine hostname without being a customer. DetectZeStack matches all of them and follows the full CNAME chain to find them, since a domain often resolves through a vanity or CDN host first. For the mechanics of chain resolution, see DNS-Based Technology Detection.

WP Engine Cache Headers and Server Fingerprints

WP Engine fronts every install with its own caching and proxy tier, and that tier writes identifiable headers into responses. The clearest is X-Powered-By: WP Engine; alongside it the platform emits WPE-Backend (naming the backend that produced the response) and cache diagnostics like X-Pass-Why and X-WPE-Loopback-Upstream-Addr. One curl -I surfaces them:

$ curl -sI https://www.example.com | grep -iE "x-powered-by|wpe|x-pass"
X-Powered-By: WP Engine
WPE-Backend: apache
X-Pass-Why:

Any one of these headers confirms the platform. They are also the reason a WP Engine detection doubles as a WordPress detection: the platform hosts WordPress exclusively, so the header implies the CMS even on sites that have stripped every conventional WordPress fingerprint—a useful backdoor when the methods in our WordPress detection guide come up empty.

Why Header Checks Alone Miss Hardened Sites

Neither layer is complete on its own. A CDN or security proxy in front of WP Engine can strip or overwrite the platform headers, so a header-only check returns a false negative for exactly the security-conscious companies you may most want to find. In those setups DNS often still tells the truth—or the reverse: a domain whose DNS routes through a CDN hides the WP Engine CNAME while the platform headers pass through the edge untouched. The practical rule: check both layers, and treat a hit on either as a confirmation. That is what the API does in a single request.

Manual Detection Methods (and Their Limits)

For one domain, the two commands above—dig ... CNAME +short and curl -sI ... | grep -iE "wpe|x-powered-by"—are all you need. The limits appear when the task changes shape:

Scale. Checking two layers by hand across a 1,000-domain prospect list is a script-writing project with retries, timeouts, and rate limiting to solve before you see a single result.
Chain resolution. dig +short shows one CNAME hop. Real domains resolve through chains—vanity host to CDN to platform—and the WP Engine hostname may sit two hops deep, where a naive check misses it.
Context. A manual check answers exactly one question. An API scan returns the entire stack—CMS, page builder, analytics, marketing tools—so the same request that confirms WP Engine also scores the lead.

Detect WP Engine with the DetectZeStack API

The API runs the header and DNS checks together, follows CNAME chains, and returns everything else it finds along the way.

Single Domain Check with /analyze (curl example)

Try it right now against the public demo endpoint—no API key required. The demo is IP-rate-limited, so use it for spot checks rather than bulk scans:

$ curl -s "https://detectzestack.com/demo?url=example.com" \
| jq '.technologies[] | select(.name == "WP Engine")'
{
"name": "WP Engine",
"categories": ["PaaS", "Hosting"],
"confidence": 100,
"description": "WP Engine is a website hosting provider.",
"website": "https://wpengine.com",
"icon": "wpengine.svg",
"source": "http",
"version": "",
"cpe": ""
}

The source field tells you which layer produced the evidence. A source: "http" entry at confidence 100 came from the platform headers—X-Powered-By: WP Engine, WPE-Backend, or one of the cache diagnostics. When only DNS gives it away, the same technology comes back with source: "dns" at confidence 80 under the Hosting category instead—reliable, but one step removed from a live header match. A header-level hit also implies WordPress, so expect a WordPress entry alongside it.

For production use, call /analyze with your API key. The complete response is shaped like this:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"url": "https://example.com",
"domain": "example.com",
"technologies": [
{
"name": "WP Engine",
"categories": ["PaaS", "Hosting"],
"confidence": 100,
"description": "WP Engine is a website hosting provider.",
"website": "https://wpengine.com",
"icon": "wpengine.svg",
"source": "http",
"version": "",
"cpe": ""
},
{
"name": "WordPress",
"categories": ["CMS", "Blogs"],
"confidence": 100,
"description": "WordPress is a free and open-source content management system written in PHP and paired with a MySQL or MariaDB database. Features include a plugin architecture and a template system.",
"website": "https://wordpress.org",
"icon": "WordPress.svg",
"source": "http",
"version": "",
"cpe": "cpe:2.3:a:wordpress:wordpress:*:*:*:*:*:*:*:*"
}
],
"categories": {
"PaaS": ["WP Engine"],
"Hosting": ["WP Engine"],
"CMS": ["WordPress"],
"Blogs": ["WordPress"]
},
"meta": { "status_code": 200, "tech_count": 2, "scan_depth": "full" },
"cached": false,
"response_ms": 1842
}

The top-level categories map groups every detection by category so you can slice the stack without iterating the array. The meta object carries the HTTP status_code, the tech_count, and the scan_depth; response_ms and cached sit at the top level, not inside meta.

meta.scan_depth matters for list building. A value of "full" means the HTTP fetch succeeded and the header check ran. A value of "partial" means the site blocked or timed out the HTTP request and only the DNS and TLS layers completed. Because WP Engine is also detectable from its CNAME suffixes, a "partial" scan can still confirm it—but an absent WP Engine entry on a "partial" scan is an unknown, not a no. Those domains belong in a retry queue.

Scanning a Lead List with /analyze/batch

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["example.com", "example.org", "example.net"]}'

The response wraps one result object per URL, each with the same shape as a single /analyze response, plus batch-level counters:

{
"results": [
{ "url": "example.com", "result": { "...full analysis..." : "" } },
{ "url": "example.org", "result": { "...full analysis..." : "" } },
{ "url": "example.net", "result": { "...full analysis..." : "" } }
],
"total_ms": 2341,
"successful": 3,
"failed": 0
}

Building a WP Engine Prospect List Workflow

Because each batch result matches the single-domain shape, the filtering logic is identical at any scale. Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10, and appends every WP Engine-confirmed domain to wpengine_leads.csv with the detection source and tech count:

#!/usr/bin/env bash
# find-wpengine.sh — filter a domain list down to WP Engine-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,source,tech_count" > wpengine_leads.csv

# 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: .}')
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" |
jq -r '.results[]
| select(.result != null)
| .result as $r
| ($r.technologies[] | select(.name == "WP Engine")) as $wpe
| [$r.domain, $wpe.source, ($r.meta.tech_count | tostring)]
| @csv' >> wpengine_leads.csv
done

wc -l wpengine_leads.csv

A 1,000-domain list becomes 100 batch calls. Recording $wpe.source per row lets you split header-confirmed hits from DNS-only ones downstream, and select(.result != null) skips domains that failed to resolve (those come back with an error field instead of a result). Three refinements worth making before outreach:

Split by source. An http-sourced hit at confidence 100 means the platform headers are live on the response right now. A dns-sourced hit at confidence 80 means the domain routes to a WP Engine hostname. Both are real customers; the first is the stronger opener.
Cross-reference the rest of the stack. The full technologies array came back with every row you kept. WP Engine plus Elementor is an agency-built marketing site; WP Engine plus WooCommerce is a store with revenue riding on uptime—different pitches to different buyers. The broader version of this segmentation is covered in finding companies using WordPress.
Score by meta.tech_count. Tech count is a rough proxy for stack maturity, useful for prioritizing which confirmed leads get personal outreach first.

Feeding these signals into a scoring model is covered in our lead enrichment pipeline guide, and the throughput, retry, and rate-limit mechanics are in how to batch scan 1,000 websites.

Widen the net to all managed WordPress hosts. WP Engine’s neighbors—Kinsta (.kinsta.cloud), Pantheon (.pantheonsite.io), Flywheel (.flywheelsites.com), and WordPress VIP (.go-vip.net)—are all detectable from their own CNAME suffixes in the same scan. If your real qualifier is “pays for managed WordPress” rather than “WP Engine specifically,” widen the jq filter to match any of them; every result row already contains the data.

Get Started with a Free API Key

The free Basic plan includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your prospect list before scaling up. Sign-up is instant through RapidAPI:

Get a key at rapidapi.com/mlugoapx/api/detectzestack.
Spot-check a domain you know: curl -s "https://detectzestack.com/demo?url=yourdomain.com" | jq '.technologies[].name'
Run the batch script above against your first 100 domains.

Conclusion

Finding companies using WP Engine comes down to reading two layers well: the X-Powered-By: WP Engine, WPE-Backend, and cache-diagnostic response headers, and the .wpengine.com, .wpenginepowered.com, and .wpeproxy.com DNS CNAMEs. Headers are the strongest signal; DNS is the reliable backup that still works when the HTTP fetch is blocked—and every confirmed hit doubles as a WordPress confirmation with hosting budget attached. A single /analyze call answers the one-domain question, /analyze/batch turns a raw list into a WP Engine-confirmed lead list, and the source and meta.scan_depth fields tell you how much to trust each row. Swap the jq filter and the same pipeline segments by Kinsta, Pantheon, or any other detectable technology instead.

How to Detect cdnjs on Any Website (API Guide)

MikeL — Tue, 30 Jun 2026 14:00:53 +0000

cdnjs is one of the most widely used free public CDNs on the web. It is a community-run, open-source library-delivery service hosted on Cloudflare's network, and it lets a developer drop a single <script> tag into a page to pull in jQuery, Font Awesome, Lodash, or almost any popular open-source package without hosting a file. That convenience is exactly why “loads assets from cdnjs” is a useful detection signal: it tells you something concrete about how a team builds and ships its front end.

This guide walks through detecting cdnjs on a website—what it actually is, where it shows up in a page's source, how to spot it manually, and how a single DetectZeStack API call returns cdnjs along with the specific libraries and versions it is delivering. We will start with a one-line check you can run right now.

What Is cdnjs and Why Detect It

cdnjs (short for “CDN for JavaScript”) is a free, open-source content delivery service that mirrors thousands of popular front-end libraries and serves them from the cdnjs.cloudflare.com hostname. Where an infrastructure CDN like Cloudflare or Amazon CloudFront proxies a whole site's traffic, cdnjs does something narrower: it hands out versioned copies of other people's open-source code so a page does not have to bundle and self-host them.

A confirmed cdnjs reference is a small but specific window into a team's front-end habits:

They lean on public CDNs for dependencies. Loading libraries from cdnjs.cloudflare.com rather than bundling and self-hosting them is a deliberate choice. It often signals a leaner build setup—static sites, server-rendered pages, or templates where a script tag is faster than running a bundler.
It usually arrives with the library it delivers. cdnjs rarely travels alone. The same page that references it is almost always loading a detectable library—jQuery, Font Awesome, a charting or animation library—so one detection often hands you a slice of the front-end stack as well.
It hints at a supply-chain posture. Teams that pull live third-party scripts from a public CDN have a different dependency surface than teams that vendor everything. For security tooling, software-composition-analysis, or subresource-integrity products, that distinction is the qualifier.

The same detection pipeline applies to any technology DetectZeStack recognizes. We have companion guides for the sibling library-delivery CDN jsDelivr and for Google Hosted Libraries—the fingerprint changes, the workflow stays the same.

How cdnjs Shows Up in a Website's Source

cdnjs is a library-delivery CDN. It exists to serve versioned, open-source assets—a specific build of jQuery, a pinned release of Font Awesome, a particular Lodash version—straight from Cloudflare-hosted mirrors. A company does not put its own domain behind cdnjs; it references cdnjs from inside its pages to fetch other people's code.

That has a direct consequence for detection. Finding cdnjs on a site does not tell you who hosts the site or how its traffic is proxied. It tells you the page intentionally pulls at least one third-party asset from cdnjs, and it points you at which asset when that asset is itself fingerprintable.

Script tags pointing to cdnjs.cloudflare.com

Every cdnjs reference resolves to the same hostname. In the page source it looks like an ordinary script or stylesheet link:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css">

The constant across all of them is the cdnjs.cloudflare.com host. That single string is the primary fingerprint: if it appears in a script src or a link href in the served HTML, the page references cdnjs. It is also why cdnjs implies Cloudflare—the service is hosted on Cloudflare's network, so a cdnjs match means the page is pulling code from a Cloudflare-hosted origin, distinct from the whole site being proxied through Cloudflare.

Library and version fingerprints cdnjs leaves behind

cdnjs URLs are unusually informative because the path is structured: /ajax/libs/<library>/<version>/<file>. The example above encodes the library (jquery) and the exact version (3.6.0) right in the URL. That structure means two things show up in a single page fetch—the delivery method (cdnjs) and the delivered library, frequently with its version parsed straight from the path.

Signal	Example	What It Tells You
cdnjs host reference	cdnjs.cloudflare.com	cdnjs confirmed (CDN)
Delivered library + version	.../ajax/libs/jquery/3.6.0/jquery.min.js	jQuery confirmed, version parsed
Self-hosted library	/static/js/jquery.min.js	Library detected, no cdnjs signal
No cdnjs reference	(none in HTML)	Page does not load assets from cdnjs

Manual Ways to Detect cdnjs (and Their Limits)

Because cdnjs lives in the page body, you can spot the raw signal yourself without any tooling. The fastest check is a single curl piped into grep:

$ curl -s https://example.com | grep -o "cdnjs\.cloudflare\.com" | head -1
cdnjs.cloudflare.com

One match is enough to confirm the page references cdnjs. To see exactly what it is pulling, widen the pattern to capture the full URLs and read the library and version out of each path:

$ curl -s https://example.com \
| grep -oE "cdnjs\.cloudflare\.com/ajax/libs/[^\"']+" | sort -u
cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js
cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.1/css/all.min.css

This works, but it has real limits when you move past one site. The reference only appears if it is present in the server-rendered HTML—a script injected later by client-side JavaScript, or one loaded through a tag manager, may not show up in a plain curl. You also have to parse each path yourself to turn it into structured data, and running this across hundreds of domains means writing your own concurrency, retry, and timeout handling. That is the gap a detection API closes: it normalizes the same body signal into clean JSON and runs it at scale.

Detect cdnjs Programmatically with the DetectZeStack API

When DetectZeStack fetches a page, it scans the HTML for script and link references to cdnjs.cloudflare.com. A match returns cdnjs under the CDN category at confidence 100, with source: "http"—because the evidence came directly from the HTTP response body.

You can try it right now against the public demo endpoint—no API key required. The demo is IP-rate-limited, so use it for spot checks rather than bulk scans:

$ curl -s "https://detectzestack.com/demo?url=example.com" \
| jq '.technologies[] | select(.name == "cdnjs")'
{
"name": "cdnjs",
"categories": ["CDN"],
"confidence": 100,
"description": "cdnjs is a free distributed JS library delivery service.",
"website": "https://cdnjs.com",
"icon": "cdnjs.svg",
"source": "http",
"version": "",
"cpe": ""
}

cdnjs is matched directly off the cdnjs.cloudflare.com reference in the page and categorized under CDN. It carries source: "http" because the evidence came from the HTTP response body, and the version field is empty—cdnjs itself is a delivery network, not a versioned library, so there is nothing to read a version from. The libraries it delivers are where versions show up.

Reading the technologies, version, and categories fields

When you want the full stack for a domain rather than a filtered slice, call /analyze with your API key. A page that loads jQuery from cdnjs comes back like this:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"url": "https://example.com",
"domain": "example.com",
"technologies": [
{
"name": "cdnjs",
"categories": ["CDN"],
"confidence": 100,
"description": "cdnjs is a free distributed JS library delivery service.",
"website": "https://cdnjs.com",
"icon": "cdnjs.svg",
"source": "http",
"version": "",
"cpe": ""
},
{
"name": "jQuery",
"categories": ["JavaScript libraries"],
"confidence": 100,
"description": "jQuery is a JavaScript library designed to simplify HTML DOM tree traversal and manipulation, as well as event handling, CSS animation, and Ajax.",
"website": "https://jquery.com",
"icon": "jQuery.svg",
"source": "http",
"version": "3.6.0",
"cpe": ""
},
{
"name": "Cloudflare",
"categories": ["CDN"],
"confidence": 100,
"description": "Cloudflare is a web-infrastructure and website-security company that provides content-delivery-network services, DDoS mitigation, and ICANN-accredited domain registration services.",
"website": "https://www.cloudflare.com",
"icon": "CloudFlare.svg",
"source": "http",
"version": "",
"cpe": ""
}
],
"categories": {
"CDN": ["cdnjs", "Cloudflare"],
"JavaScript libraries": ["jQuery"]
},
"meta": { "status_code": 200, "tech_count": 3, "scan_depth": "full" },
"cached": false,
"response_ms": 1842
}

Three entries from one page. cdnjs is the delivery method; jQuery is the thing being delivered, with its version parsed from the script URL; and Cloudflare appears because cdnjs is hosted on Cloudflare's network and its fingerprint implies Cloudflare. The top-level categories map groups every detection, so you can pull all CDNs with .categories["CDN"] without iterating the array. The meta object carries the HTTP status_code, the tech_count, and the scan_depth; response_ms and cached sit at the top level.

One field to watch for list building is meta.scan_depth. A value of "full" means the HTTP fetch succeeded and body detection ran. A value of "partial" means the site blocked or timed out the HTTP request and only DNS and TLS layers completed—and since cdnjs lives in the body, an absent cdnjs entry on a "partial" scan tells you nothing. Those domains belong in a retry queue, not your rejects file.

The honest limitation: cdnjs detection depends on the HTML actually containing the reference. If a script is injected later by client-side JavaScript that never runs during a server-side fetch, or if the reference sits behind a tag manager, it may not appear in the fetched body. As with any body-fingerprint signal, absence of a detection is an unknown, not proof the site never touches cdnjs.

Detecting cdnjs Across Many Sites at Scale

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently. Each entry in the response carries either a full analysis result or an error for domains that could not be fetched:

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["example.com", "getbootstrap.com", "wordpress.org"]}'

The response wraps one result object per URL, each with the same shape as a single /analyze response:

{
"results": [
{ "url": "example.com",       "result": { "...full analysis..." : "" } },
{ "url": "getbootstrap.com",   "result": { "...full analysis..." : "" } },
{ "url": "wordpress.org",      "result": { "...full analysis..." : "" } }
],
"total_ms": 2341,
"successful": 3,
"failed": 0
}

Because each result matches the single-domain shape, the filtering logic is identical whether you scan one domain or a thousand. Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10 to /analyze/batch, and appends every domain where cdnjs is detected to cdnjs_leads.csv, recording the tech count alongside it:

#!/usr/bin/env bash
# find-cdnjs.sh — filter a domain list down to cdnjs-confirmed sites
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,tech_count" > cdnjs_leads.csv

# 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: .}')
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" |
jq -r '.results[]
| select(.result != null)
| .result as $r
| select([$r.technologies[].name] | index("cdnjs"))
| [$r.domain, ($r.meta.tech_count | tostring)]
| @csv' >> cdnjs_leads.csv
done

wc -l cdnjs_leads.csv

A 1,000-domain list becomes 100 batch calls. The index("cdnjs") guard keeps a domain whenever cdnjs appears in its technology list, and select(.result != null) skips domains that failed to resolve (those come back with an error field instead of a result). For a deeper treatment of batch throughput, retries, and a production Python scanner, see how to batch scan 1,000 websites.

If you want to segment by the library cdnjs is delivering rather than just the delivery method, widen the filter to capture the co-detected technologies—the same technologies array already carries jQuery, Font Awesome, and whatever else the page pulls in. Our guides on detecting jQuery and the broader JavaScript framework detection cover those fingerprints in detail.

cdnjs vs Other JavaScript CDNs

“CDN” is an overloaded word, and it helps to be precise about where cdnjs sits. There are two very different things both called CDNs:

Type	Examples	Detected From
Infrastructure CDN	Cloudflare, Fastly, Amazon CloudFront, Akamai	DNS CNAME, response headers, TLS certificate
Library-delivery CDN	cdnjs, jsDelivr, unpkg, Google Hosted Libraries	Script & link references in the page HTML

An infrastructure CDN proxies the whole site, so it shows up in the site's DNS, headers, and certificate—the layer covered in how to detect a website's CDN and hosting provider and, for one specific provider, finding companies using Amazon CloudFront. cdnjs sits in the other column: it is detected purely from references inside the served HTML, alongside its peers jsDelivr (cdn.jsdelivr.net), unpkg (unpkg.com), and Google Hosted Libraries (ajax.googleapis.com).

cdnjs is closest to jsDelivr—both serve open-source libraries from a public mirror—with one wrinkle: cdnjs is hosted on Cloudflare, so its detection implies Cloudflare, while jsDelivr is independent. The flip side of both is the self-hosted case. A team that runs a bundler and ships its libraries from its own domain will load, say, jQuery from /static/js/jquery.min.js—no cdnjs reference at all. The library is still detectable on its own fingerprint, but the delivery signal is absent. A missing cdnjs detection does not mean the site avoids jQuery; it means the site does not fetch jQuery from cdnjs. Keep that distinction in mind when you read negatives.

Get Your API Key and Start Detecting cdnjs

The free tier includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your domain list before scaling up. Sign-up is instant through RapidAPI:

Get a key at rapidapi.com/mlugoapx/api/detectzestack.
Spot-check a domain you know: curl -s "https://detectzestack.com/demo?url=yourdomain.com" | jq '.technologies[].name'
Run the batch script above against your first 100 domains.

Conclusion

Detecting cdnjs comes down to reading one thing well: a cdnjs.cloudflare.com reference in the page HTML. Because cdnjs is a library-delivery CDN rather than an infrastructure one, it is detected from the body, not from DNS or headers—and the real prize is usually the library it carries, whose name and version are encoded right in the URL path and returned alongside it. A single /analyze call answers the one-domain question; /analyze/batch turns a raw domain list into a cdnjs-confirmed list; and meta.scan_depth tells you which negatives are real and which are unknowns worth a retry. Swap the jq filter and the same pipeline segments by front-end library, infrastructure CDN, or backend runtime instead.

Find Companies Using jsDelivr: Technographic API Guide

MikeL — Mon, 22 Jun 2026 14:00:54 +0000

jsDelivr is one of the most widely used free public CDNs on the web. It serves open-source files directly from the npm registry and GitHub repositories, which means a developer can drop a single <script> tag into a page and pull in Bootstrap, Chart.js, a jQuery plugin, or almost any published package without hosting a thing themselves. That convenience is exactly what makes “uses jsDelivr” an interesting technographic signal: it tells you something about how a team builds and ships front-end code.

This guide explains what jsDelivr usage actually reveals about a company, why it is detected differently from an infrastructure CDN like Cloudflare, and how to turn a raw domain list into a jsDelivr-confirmed lead list with the DetectZeStack API—starting with a single curl command you can run right now.

Why Find Companies Using jsDelivr?

Technographic data—what technology a company runs—is frequently a stronger qualifier than firmographics alone. A confirmed jsDelivr reference is a small but specific window into a team's front-end habits:

They lean on public CDNs for dependencies. Loading libraries from cdn.jsdelivr.net rather than bundling and self-hosting them is a deliberate choice. It often signals a leaner build setup—static sites, server-rendered pages, or templates where pulling a script tag is faster than running a bundler.
It usually comes bundled with the library it delivers. jsDelivr rarely travels alone. The same page that references it is almost always loading a detectable library—Bootstrap, Chart.js, a charting or carousel plugin—so one detection often hands you the front-end stack as well.
It hints at a security and supply-chain posture. Teams that pull live third-party scripts from a public CDN have a different dependency surface than teams that vendor everything. For security tooling, SCA, or subresource-integrity products, that distinction is the qualifier.

The same pipeline applies to any detectable technology. We have companion guides for finding companies using Node.js and the broader topic of detecting a site's CDN and hosting provider—the filter changes, the workflow stays the same.

What jsDelivr Tells You About a Tech Stack

jsDelivr is a library-delivery CDN. It exists to serve versioned, open-source assets—a specific build of Bootstrap, a pinned release of Chart.js, a Vue component—straight from npm or GitHub. A company does not put its own domain behind jsDelivr; it references jsDelivr from inside its pages to fetch other people's code.

That has a direct consequence for what a detection means. Finding jsDelivr on a site does not tell you who hosts the site or how its traffic is proxied. It tells you the page intentionally pulls at least one third-party asset from a public CDN, and it points you at which asset when that asset is itself fingerprintable.

jsDelivr vs Self-Hosted Libraries and Other CDNs

It is worth being precise about where jsDelivr sits, because “CDN” is an overloaded word. There are two very different things both called CDNs:

Type	Examples	Detected From
Infrastructure CDN	Cloudflare, Fastly, CloudFront, Akamai	DNS CNAME, response headers, TLS certificate
Library-delivery CDN	jsDelivr, cdnjs, unpkg, Google Hosted Libraries	Script & link references in the page HTML

An infrastructure CDN proxies the whole site, so it shows up in the site's DNS, headers, and certificate—the layer covered in how to detect a website's CDN and hosting provider. jsDelivr leaves none of those marks, because it never touches the site's own domain. It appears only as a reference inside the served HTML, alongside its peers cdnjs (cdnjs.cloudflare.com), unpkg (unpkg.com), and Google Hosted Libraries (ajax.googleapis.com).

The flip side is the self-hosted case. A team that runs a bundler and ships its libraries from its own domain will load, say, Bootstrap from /static/js/bootstrap.min.js—no jsDelivr reference at all. The library is still detectable on its own fingerprint, but the delivery signal is absent. In other words: a missing jsDelivr detection does not mean the site avoids Bootstrap; it means the site does not fetch Bootstrap from jsDelivr. Keep that distinction in mind when you read negatives.

How DetectZeStack Detects jsDelivr

Because jsDelivr lives in the page body, detection is a body-fingerprint match, not a DNS or header lookup. When DetectZeStack fetches a page, it scans the HTML for script and link references to cdn.jsdelivr.net. A match returns jsDelivr under the CDN category, at confidence 100, with source: "http"—because the evidence came directly from the HTTP response body.

You can spot the same raw signal yourself with a single command:

$ curl -s https://example.com | grep -o "cdn\.jsdelivr\.net" | head -1
cdn.jsdelivr.net

One match is enough to confirm the page references jsDelivr. The value the API adds is what comes with it: many of the libraries delivered over jsDelivr have their own fingerprints, so a single scan typically returns jsDelivr plus whatever it is delivering. A page that loads Chart.js from a cdn.jsdelivr.net path, for example, comes back with both jsDelivr (under CDN) and Chart.js as separate entries—often with a version parsed straight from the URL.

Signal	Example	What It Tells You
jsDelivr script source	cdn.jsdelivr.net	jsDelivr confirmed (CDN)
Delivered library	.../npm/chart.js@4/dist/chart.js	Chart.js confirmed, version parsed
Self-hosted library	/static/js/bootstrap.min.js	Library detected, no jsDelivr signal
No jsDelivr reference	(none in HTML)	Site does not load assets from jsDelivr

The honest limitation: jsDelivr detection depends on the HTML actually containing the reference. If a script is injected later by client-side JavaScript that never runs during a server-side fetch, or if the reference sits behind a tag manager, it may not appear in the fetched body. As with any body-fingerprint signal, absence of a detection is an unknown, not proof the site never touches jsDelivr.

API Example: Detecting jsDelivr With a Single Call

You can try detection right now against the public demo endpoint—no API key required. The demo is IP-rate-limited, so use it for spot checks rather than bulk scans:

$ curl -s "https://detectzestack.com/demo?url=example.com" \
| jq '.technologies[] | select(.name == "jsDelivr")'
{
"name": "jsDelivr",
"categories": ["CDN"],
"confidence": 100,
"description": "JSDelivr is a free public CDN for open-source projects. It can serve web files directly from the npm registry and GitHub repositories without any configuration.",
"website": "https://www.jsdelivr.com/",
"icon": "jsdelivr-icon.svg",
"source": "http",
"version": "",
"cpe": ""
}

jsDelivr is matched directly off the cdn.jsdelivr.net reference in the page and categorized under CDN. It carries source: "http" because the evidence came from the HTTP response body, and the version field is empty—jsDelivr itself is a delivery network, not a versioned library, so there is nothing to read a version from. The libraries it delivers are where versions show up.

When you want the full stack for a domain rather than a filtered slice, call /analyze with your API key. The complete response is shaped like this:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"url": "https://example.com",
"domain": "example.com",
"technologies": [
{
"name": "jsDelivr",
"categories": ["CDN"],
"confidence": 100,
"description": "JSDelivr is a free public CDN for open-source projects. It can serve web files directly from the npm registry and GitHub repositories without any configuration.",
"website": "https://www.jsdelivr.com/",
"icon": "jsdelivr-icon.svg",
"source": "http",
"version": "",
"cpe": ""
},
{
"name": "Chart.js",
"categories": ["JavaScript graphics"],
"confidence": 100,
"description": "Chart.js is a free, open-source JavaScript library for data visualization.",
"website": "https://www.chartjs.org",
"icon": "Chart.js.svg",
"source": "http",
"version": "4.4.1",
"cpe": ""
}
],
"categories": {
"CDN": ["jsDelivr"],
"JavaScript graphics": ["Chart.js"]
},
"meta": { "status_code": 200, "tech_count": 2, "scan_depth": "full" },
"cached": false,
"response_ms": 1842
}

Two entries from one page: jsDelivr as the delivery method and Chart.js as the thing being delivered, with its version parsed from the script URL. The top-level categories map groups every detection so you can pull all CDNs with .categories["CDN"] without iterating the array. The meta object carries the HTTP status_code, the tech_count, and the scan_depth; response_ms and cached sit at the top level.

One field to watch for list building is meta.scan_depth. A value of "full" means the HTTP fetch succeeded and body detection ran. A value of "partial" means the site blocked or timed out the HTTP request and only DNS and TLS layers completed—and since jsDelivr lives in the body, an absent jsDelivr entry on a "partial" scan tells you nothing. Those domains belong in a retry queue, not your rejects file.

Building a List of Companies Using jsDelivr at Scale

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["example.com", "getbootstrap.com", "wordpress.org"]}'

The response wraps one result object per URL, each with the same shape as a single /analyze response:

{
"results": [
{ "url": "example.com",       "result": { "...full analysis..." : "" } },
{ "url": "getbootstrap.com",   "result": { "...full analysis..." : "" } },
{ "url": "wordpress.org",      "result": { "...full analysis..." : "" } }
],
"total_ms": 2341,
"successful": 3,
"failed": 0
}

Because each result matches the single-domain shape, the filtering logic is identical whether you scan one domain or a thousand. Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10 to /analyze/batch, and appends every domain where jsDelivr is detected to jsdelivr_leads.csv, recording the tech count alongside it:

#!/usr/bin/env bash
# find-jsdelivr.sh — filter a domain list down to jsDelivr-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,tech_count" > jsdelivr_leads.csv

# 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: .}')
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" |
jq -r '.results[]
| select(.result != null)
| .result as $r
| select([$r.technologies[].name] | index("jsDelivr"))
| [$r.domain, ($r.meta.tech_count | tostring)]
| @csv' >> jsdelivr_leads.csv
done

wc -l jsdelivr_leads.csv

A 1,000-domain list becomes 100 batch calls. The index("jsDelivr") guard keeps a domain whenever jsDelivr appears in its technology list, and select(.result != null) skips domains that failed to resolve (those come back with an error field instead of a result). For a deeper treatment of batch throughput, retries, and a production Python scanner, see how to batch scan 1,000 websites.

If you want to segment by the library jsDelivr is delivering rather than just the delivery method, widen the filter to capture the co-detected technologies—the same technologies array already carries Chart.js, Bootstrap, jQuery, and whatever else the page pulls in. Our guides on detecting jQuery and the broader JavaScript framework detection cover those fingerprints in detail.

Use Cases: Sales, Competitive Intelligence, and Security

A jsDelivr-confirmed list is rarely the end goal on its own—it is the entry point to a more specific segment. Three common ways teams use it:

Sales and prospecting. Pair the jsDelivr flag with the library it delivers. A list of sites pulling a specific charting or UI library from jsDelivr is a precise audience if you sell a competing or complementary front-end product. The delivery method narrows the list; the delivered library qualifies it.
Competitive intelligence. Scanning a market segment for public-CDN usage tells you how teams in that space build. A cohort that leans heavily on jsDelivr and cdnjs is shipping differently than one that bundles and self-hosts everything—useful context when you are studying how an entire market makes front-end decisions.
Security and supply-chain mapping. Every live third-party script is part of a site's dependency surface. Security teams use technographic scans to inventory which external CDNs a domain pulls executable code from, which feeds subresource-integrity audits and third-party-risk reviews. The CDN category is exactly the layer they need to enumerate.

Two practical enrichment moves once the list is built: cross-reference the infrastructure CDN to separate “loads libraries from jsDelivr” from “proxied through Cloudflare”—they are independent signals and a site commonly has both—and score by meta.tech_count, a rough proxy for how built-out a company's front end is. Feeding those signals into a scoring model is covered in our lead enrichment pipeline guide.

Get Started With the DetectZeStack API

The free tier includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your prospect list before scaling up. Sign-up is instant through RapidAPI:

Get a key at rapidapi.com/mlugoapx/api/detectzestack.
Spot-check a domain you know: curl -s "https://detectzestack.com/demo?url=yourdomain.com" | jq '.technologies[].name'
Run the batch script above against your first 100 domains.

Conclusion

Finding companies using jsDelivr comes down to reading one thing well: a cdn.jsdelivr.net reference in the page HTML. Because jsDelivr is a library-delivery CDN rather than an infrastructure one, it is detected from the body, not from DNS or headers—and the real prize is usually the library it carries, which a single scan returns alongside it. A single /analyze call answers the one-domain question; /analyze/batch turns a raw domain list into a jsDelivr-confirmed lead list; and meta.scan_depth tells you which negatives are real and which are unknowns worth a retry. Swap the jq filter and the same pipeline segments by infrastructure CDN, front-end library, or backend runtime instead.

How to Find Companies Using MySQL: API Guide for 2026

MikeL — Sun, 14 Jun 2026 14:01:17 +0000

MySQL has been the default database of the web for two decades. It sits underneath WordPress, Magento, PrestaShop, and a long tail of forums, wikis, and self-hosted tools—which means a list of companies using MySQL is really a list of companies running real, database-backed applications. If you sell database tooling, managed hosting, backup services, migration consulting, or performance monitoring, that list is your pipeline.

There is a catch, and most guides skip it: you cannot detect MySQL directly from outside a website. The database never talks to the browser. This guide explains how MySQL detection actually works (inference through the application layer), how reliable those inferences are, and how to turn a raw domain list into a MySQL-confirmed prospect list with the DetectZeStack API—single checks, batch scans, and side-by-side comparison included.

Why Build a List of Companies Using MySQL

Who Uses MySQL Lists: Sales, DevRel, Security, and Migration Vendors

MySQL technographics serve a wider set of buyers than most technology filters:

Database and infrastructure vendors. Managed MySQL hosting, backup-as-a-service, replication tooling, query performance monitors—every one of these products has “runs MySQL” as its first qualifying question. A confirmed detection replaces a discovery call.
Migration and consulting shops. Teams selling PostgreSQL migrations, cloud database moves, or version-upgrade services need to find MySQL estates before they can pitch replacing or modernizing them.
DevRel and developer marketing. If your product integrates with MySQL—an ORM, a CDC pipeline, a caching layer—the companies already running it are the audience for your content and outreach.
Security teams. MySQL detections come with a CPE identifier (cpe:2.3:a:mysql:mysql), which plugs directly into vulnerability workflows. An external scan of your vendors’ domains tells you which ones run MySQL-backed platforms worth asking about in a security review. Our CPE guide for security teams covers that pipeline end to end.

The workflow below is the same one we documented for finding companies using Nginx and finding companies using Stripe—only the filter changes. What makes the MySQL version interesting is how the detection happens.

How MySQL Detection Works (and Its Limits)

A web server announces itself in the Server header. A JavaScript framework leaves fingerprints all over the HTML. MySQL does neither—it listens on port 3306 behind a firewall and speaks only to the application. There is no header, cookie, or script tag that says “MySQL.”

So external detection works by implication. The fingerprint database knows that certain applications are built on MySQL. When one of those applications is detected through its own (very visible) fingerprints, MySQL is added to the result as an implied technology. Detect WordPress, and you have detected MySQL, because WordPress does not run without it.

Indirect Signals: CMS and Ecommerce Platform Implications

Dozens of detectable platforms carry a MySQL implication. The ones you will encounter most in real scans:

Platform	Category	What It Means for Your List
WordPress	CMS / Blogs	The single biggest MySQL signal on the web—every WordPress site is a MySQL (or MariaDB) site
Magento	Ecommerce	Larger ecommerce operations with real database load—prime targets for performance tooling
PrestaShop	Ecommerce	SMB ecommerce, heavily represented in Europe
OpenCart	Ecommerce	Self-hosted SMB stores, often on shared or VPS hosting
Shopware	Ecommerce	Mid-market ecommerce, strong in the DACH region
Flarum / Invision Power Board	Forums	Community-run infrastructure with long-lived databases
BookStack / MantisBT / Piwigo	Self-hosted tools	Teams that self-host internal tooling—a strong “runs own infrastructure” signal

Two honest caveats before you build a pipeline on this:

MySQL vs MariaDB is invisible from outside. WordPress and most of the platforms above run equally well on MariaDB, a drop-in replacement. External detection cannot tell which fork is actually installed—treat the detection as “MySQL-compatible database” when precision matters.
Not every MySQL-implying platform is in the chain. Notably, Drupal supports several databases and therefore does not imply MySQL in the fingerprint data, even though many Drupal sites do run it. The implication list is deliberately conservative: it only includes platforms where MySQL is a hard requirement.

Why Server-Side Databases Are Harder to Detect Than Frontend Tech

This inference model has an asymmetry you need to internalize before trusting your lead list:

Positives are strong. If the API reports MySQL, a MySQL-requiring platform was detected at full confidence. The implication is definitional, not statistical—there is no such thing as a WordPress site without a MySQL-compatible database behind it.
Negatives are unknowns. A custom Laravel app, a Rails monolith, or a Django site can all run MySQL without exposing any platform fingerprint that implies it. No detection does not mean no MySQL—it means no visible evidence. Score these domains as “unknown,” not “disqualified.”

This is the database equivalent of the CDN-masking problem we covered in the Nginx guide: external scanning gives you high-precision positives and ambiguous negatives. Good pipelines keep the two piles separate.

Find MySQL-Backed Sites with the DetectZeStack API

The API runs the full detection pass—HTTP fingerprints, DNS records, and TLS certificates—in one call, resolves the implication chains, and returns structured JSON. You can try it right now against the public demo endpoint, no API key required (it is IP-rate-limited, so use it for spot checks, not bulk scans):

$ curl -s "https://detectzestack.com/demo?url=wordpress.org" \
| jq '.technologies[] | select(.name == "MySQL")'
{
"name": "MySQL",
"categories": ["Databases"],
"confidence": 100,
"description": "MySQL is an open-source relational database management system.",
"website": "https://mysql.com",
"icon": "MySQL.svg",
"cpe": "cpe:2.3:a:mysql:mysql:*:*:*:*:*:*:*:*",
"source": "http"
}

That is a real response. MySQL appears under the Databases category at confidence 100—the implying platform (WordPress, in this case) was an HTTP-layer match, and the implication inherits its confidence. The cpe field is ready for vulnerability tooling. Note there is no version field: an implied database carries no version information, because the version lives server-side where no scanner can see it.

The top-level categories map gives you a shortcut—you can check for any database without iterating the technologies array:

$ curl -s "https://detectzestack.com/demo?url=wordpress.org" \
| jq '.categories["Databases"]'
[
"MySQL"
]

Single Domain Check with /analyze

With an API key, /analyze is the authenticated equivalent—same response shape, your own rate limits, and results cached for repeat lookups:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=example-store.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
| jq '{domain, mysql: (.categories["Databases"] // [] | contains(["MySQL"])), via: .categories["CMS"], tech_count: .meta.tech_count}'
{
"domain": "example-store.com",
"mysql": true,
"via": ["WordPress"],
"tech_count": 14
}

When all you need is the boolean, the /check endpoint is the cheapest call—pass the domain and tech=mysql (the parameter is case-insensitive):

$ curl -s "https://detectzestack.p.rapidapi.com/check?url=wordpress.org&tech=mysql" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
"domain": "wordpress.org",
"technology": "MySQL",
"detected": true,
"confidence": 100,
"version": "",
"categories": ["Databases"],
"response_ms": 1204,
"cached": false
}

Scaling Up with POST /analyze/batch

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently. Here is a complete pipeline using bash, curl, and jq that reads domains.txt (one domain per line) and writes every MySQL-confirmed domain to mysql_leads.csv, annotated with the platform that implied the database:

#!/usr/bin/env bash
# find-mysql.sh — filter a domain list down to MySQL-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,platform,tech_count" > mysql_leads.csv

# 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: .}')
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" |
jq -r '.results[]
| select(.result != null)
| select(.result.categories["Databases"] // [] | contains(["MySQL"]))
| [.result.domain,
((.result.categories["CMS"] // .result.categories["Ecommerce"] // ["unknown"])[0]),
(.result.meta.tech_count | tostring)]
| @csv' >> mysql_leads.csv
done

wc -l mysql_leads.csv

A 1,000-domain list becomes 100 batch calls. Domains that fail to resolve or time out appear in results[] with an error field instead of a result, and the select(.result != null) guard skips them cleanly. One more filter worth adding for data quality: check meta.scan_depth. A value of "partial" means the HTTP fetch failed and only DNS and TLS layers ran—since MySQL implications come from HTTP-layer platform detection, a partial scan can never find MySQL, and those domains belong in a retry queue rather than your rejects file. For throughput, retries, and a production Python version of this scanner, see how to batch scan 1,000 websites.

Building a Prospect List: From Detection to Outreach

The CSV above is a lead list, but the platform column is what makes it routable. A MySQL detection via Magento and one via WordPress describe very different companies:

WordPress + MySQL — could be anything from a hobby blog to an enterprise content site. Qualify further on tech_count and the rest of the stack: a site also running a tag manager, a CRM widget, and a CDN is a business; fifteen plugins and shared hosting is not your enterprise buyer. Our guide to checking if a website uses WordPress covers reading those secondary signals.
Magento / Shopware + MySQL — transactional databases under real load. These companies feel query latency in revenue and are the natural audience for performance and reliability tooling.
Self-hosted tools (BookStack, MantisBT) + MySQL — engineering-led teams that run their own infrastructure and can actually install what you sell.

Comparing Two Prospects with POST /compare

When you are deciding which of two accounts to work first, POST /compare analyzes 2–10 domains in one call and computes the shared and unique technologies across them:

$ 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": ["prospect-a.com", "prospect-b.com"]}' \
| jq '{shared, unique_a: .domains[0].unique, unique_b: .domains[1].unique}'
{
"shared": ["WordPress", "MySQL", "PHP", "Nginx"],
"unique_a": ["WooCommerce", "Cloudflare"],
"unique_b": ["HubSpot"]
}

Both prospects run WordPress on MySQL, but prospect A added ecommerce (WooCommerce)—its database is taking orders, not just serving pages. If you sell backup or performance tooling, A goes to the top of the queue. The full response also carries each domain’s complete technologies array, so one compare call doubles as two enrichment calls. Feeding these signals into a scoring model is covered in our lead enrichment pipeline guide.

MySQL Detection vs Other Technographic Tools

Every external technographic tool—ours included—detects databases the same way, because there is only one way: implication through the application layer. The differences that actually matter when you evaluate tools for a MySQL pipeline:

Live scans vs stored indexes. Directory-style tools answer from a crawl that may be months old; a site that migrated off Magento last quarter still shows as a MySQL lead. DetectZeStack scans the domain at request time, so the detection reflects today’s stack. (Results are cached briefly for repeat lookups—the cached field in every response tells you which you got.)
Structured output. A boolean from /check, a filterable categories map from /analyze, and CPE identifiers on every detection that has one—built for scripts rather than screenshots.
Cost at list-building volume. Enterprise technographic platforms price for sales teams buying exports. If what you need is “run my own domain list through a detector,” API pricing is an order of magnitude cheaper—we did the math in our technographic data pricing breakdown.

Conclusion and Next Steps

Finding companies using MySQL means accepting how database detection really works: there is no direct fingerprint, only implication through platforms like WordPress, Magento, PrestaShop, and OpenCart that cannot run without it. That gives you high-precision positives (the implication is definitional), negatives that are really unknowns (custom apps hide their database), and one structural blind spot (MySQL vs MariaDB is indistinguishable from outside).

The pipeline itself is three calls: /demo or /check to validate the approach on domains you know, /analyze/batch to turn a raw domain list into a platform-annotated MySQL lead list, and /compare to rank the prospects you are about to work. The free tier’s 100 requests per month are enough to validate the pipeline on a sample of your list before scaling up.

DNS Lookup API: MX, NS, SPF, DMARC via REST (2026)

MikeL — Sat, 06 Jun 2026 14:01:20 +0000

Most engineers default to dig when they need to look at a domain's DNS. It's fast, it's local, and it's correct. But the moment you need DNS records inside a script, a webhook handler, a CI pipeline, a Slack bot, or a lead-enrichment job, parsing dig's text output becomes a chore. A DNS lookup API gives you the same answers as structured JSON: one HTTP call, one parser, every record type in one shot.

This post walks through what a DNS lookup API does, which records the DetectZeStack GET /dns endpoint returns, how the email-security grading on top of those records works, and where it beats the shell-out-to-dig pattern. Every example uses the real API; none of the field names are invented.

What a DNS Lookup API Does (and Why You Need One)

DNS is the connective tissue of the public internet. Every domain answers questions about itself through DNS: where its web servers live (A, AAAA), where its mail goes (MX), who can sign for it (NS, SOA), what the apex is aliased to (CNAME), and what arbitrary metadata the owner has chosen to publish (TXT — including SPF, DMARC, Google Search Console verification, and dozens of other conventions).

A DNS lookup API exists because the data is useful in places where running dig isn't practical:

A serverless function that needs to know a prospect's email provider before deciding which outreach template to send
A change-monitoring job that polls a domain every week and posts to Slack when its nameservers move
A CRM enrichment hook that wants the email_security_grade for a domain at lead-creation time
An M&A diligence dashboard that audits 200 portfolio companies' SPF and DMARC posture nightly
A browser-side tool that can't make raw DNS queries because the browser only speaks HTTP

In all of those, you don't want to package dig as a dependency, parse its text output, handle stderr, and figure out which selectors to probe for DKIM. You want JSON.

Records You Can Query: A, AAAA, MX, NS, TXT, SOA, CNAME, PTR

The DetectZeStack GET /dns endpoint resolves all of the standard public DNS record types in a single call. The response is a JSON object with one field per record type:

Field	Description
a	IPv4 address records (list of strings)
aaaa	IPv6 address records (list of strings)
cname	Canonical name (string; empty when not present at the queried label)
mx	Mail exchange records as {host, priority} objects
ns	Authoritative nameservers (list of strings)
txt	All TXT records (list of strings, including SPF and verification tokens)
soa	Start-of-authority record with primary_ns, admin_email, serial, refresh, retry, expire, min_ttl
ptr	Reverse DNS for the first A record (list of strings)
email_provider	Identified email provider from MX records (Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, etc.)
dns_provider	Identified DNS provider from NS records (Cloudflare, Route 53, Google Cloud DNS, GoDaddy, etc.)
query_ms	Total DNS resolution time in milliseconds
response_ms	End-to-end API response time in milliseconds (top-level)

The endpoint sets a 5-second hard cap on a single lookup. If a record type can't be resolved (typical for AAAA on IPv4-only domains, or PTR when no rDNS is published), the field is returned as an empty array rather than as an error — you get all the records that exist in one call instead of having to retry for each missing type.

Email Security Records: SPF, DMARC, DKIM

SPF and DMARC are plain TXT records. DKIM is a TXT record at a <selector>._domainkey.<domain> label. If you only ask DNS for them, you get raw strings — v=spf1 include:_spf.google.com ~all, v=DMARC1; p=reject; rua=mailto:dmarc@... — and then you have to parse them yourself.

The /dns endpoint parses them for you and adds them as separate top-level fields:

spf — the parsed SPF record with record, exists, mechanism (-all / ~all / ?all / +all), includes (list of include domains), a letter grade, and a list of issues
dmarc — the parsed DMARC record with record, exists, policy (reject / quarantine / none), subdomain_policy, aggregate reporting URI (rua), forensic URI (ruf), grade, and issues
dkim — the DKIM probe result: which selector was tested (selector_tested), whether a record exists, a grade, and any issues

How DetectZeStack Grades Email Security

Each protocol gets an A–F letter grade, and an overall email_security_grade is computed from the three. The logic, briefly:

SPF — An A requires -all (hardfail) and fewer than 10 DNS-lookup includes (RFC 7208 caps SPF at 10 lookups). ~all (softfail) scores a B. Missing or +all is an F.
DMARC — p=reject with rua reporting earns an A. p=quarantine is a B. p=none (monitor-only) is a C. No record is an F.
DKIM — The API probes 8 common selectors: google, default, selector1, selector2, k1, mandrill, mailchimp, smtp. If any selector returns a valid record, DKIM grades A. None found grades F.

The composite email_security_grade is dragged down by the weakest of the three. A single F on any one of SPF, DMARC, or DKIM stops the overall grade from being an A. The email_security_summary field is a human-readable sentence you can drop straight into a Slack message or a CRM note.

If you want the full breakdown of SPF/DMARC/DKIM checks beyond what's in this post, see DNS Intelligence API: SPF, DKIM & DMARC Check.

DNS Lookup API vs Running `dig` Yourself

Both approaches resolve the same records. The difference is everything that surrounds the resolution:

Capability	dig / nslookup	DetectZeStack /dns
One record type per command	Yes — dig MX, dig TXT, dig NS separately	All record types in one call
Output format	Text (zone-file style)	JSON
Email-provider identification	Read MX records, classify by hand	Automatic
DNS-provider identification	Read NS records, classify by hand	Automatic
SPF parsing & grading	Manual (read TXT, interpret)	Built in
DMARC parsing & grading	Manual (dig _dmarc. TXT)	Built in
DKIM probing	Guess selectors, query each	8 common selectors probed
Works from browser / serverless	No (needs OS DNS client)	Yes (just HTTP)
Batch automation	Bash + xargs + parsing	Plain HTTP requests in any language

dig is the right tool when you're sitting at a terminal debugging one domain. The API is the right tool when the answer needs to flow into another system — a Slack alert, a Postgres row, a Notion page, a CRM enrichment field, a CI assertion.

Using the DetectZeStack /dns Endpoint (curl example)

Grab a free RapidAPI key from the DetectZeStack listing (no credit card required, 100 requests per month on the free plan), then call /dns with a domain query parameter:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=stripe.com" \
-H "x-rapidapi-key: YOUR_API_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" | python3 -m json.tool

If you just want to see the shape of the response without an API key, the public /demo endpoint returns the same kind of structured data for the tech-detection side of the API (no key required). You can use it as a smoke test before wiring up your real key:

curl -s "https://detectzestack.com/demo?url=https://stripe.com" | python3 -m json.tool

That call returns the technology-detection response shape:

{
"url": "https://stripe.com",
"domain": "stripe.com",
"technologies": [
{
"name": "React",
"categories": ["JavaScript frameworks"],
"confidence": 100,
"description": "React is an open-source JavaScript library for building user interfaces.",
"website": "https://reactjs.org",
"icon": "React.svg",
"source": "http",
"version": "",
"cpe": ""
},
{
"name": "Cloudflare",
"categories": ["CDN"],
"confidence": 100,
"description": "Cloudflare is a global CDN and DDoS-mitigation network.",
"website": "https://www.cloudflare.com",
"icon": "CloudFlare.svg",
"source": "http",
"version": "",
"cpe": ""
}
],
"categories": { "JavaScript frameworks": ["React"], "CDN": ["Cloudflare"] },
"meta": { "status_code": 200, "tech_count": 14, "scan_depth": "full" },
"cached": false,
"response_ms": 1842
}

Use /demo to confirm the auth-free flow works, then point at /dns with your key for the DNS-specific records.

Sample JSON Response

A realistic /dns response looks like this:

{
"domain": "stripe.com",
"a": ["185.166.143.26", "185.166.143.18"],
"aaaa": [],
"cname": "",
"mx": [
{"host": "aspmx.l.google.com.", "priority": 1},
{"host": "alt1.aspmx.l.google.com.", "priority": 5},
{"host": "alt2.aspmx.l.google.com.", "priority": 5}
],
"ns": [
"ns-cloud-a1.googledomains.com.",
"ns-cloud-a2.googledomains.com.",
"ns-cloud-a3.googledomains.com.",
"ns-cloud-a4.googledomains.com."
],
"txt": [
"v=spf1 include:_spf.google.com include:servers.mcsv.net ~all",
"google-site-verification=...",
"MS=ms..."
],
"soa": {
"primary_ns": "ns-cloud-a1.googledomains.com.",
"admin_email": "cloud-dns-hostmaster.google.com.",
"serial": 4,
"refresh": 21600,
"retry": 3600,
"expire": 1209600,
"min_ttl": 300
},
"ptr": ["185-166-143-26.example.ptr."],
"email_provider": "Google Workspace",
"dns_provider": "Google Cloud DNS",
"spf": {
"record": "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all",
"exists": true,
"mechanism": "~all",
"includes": ["_spf.google.com", "servers.mcsv.net"],
"grade": "B",
"issues": ["Uses ~all (softfail) instead of -all (hardfail)"]
},
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc@stripe.com",
"exists": true,
"policy": "reject",
"subdomain_policy": "",
"rua": "mailto:dmarc@stripe.com",
"ruf": "",
"grade": "A",
"issues": []
},
"dkim": {
"selector_tested": "google",
"exists": true,
"grade": "A",
"issues": []
},
"email_security_grade": "A",
"email_security_summary": "Strong email security posture. SPF, DMARC, and DKIM are all configured.",
"query_ms": 142,
"response_ms": 168
}

One request, full DNS picture. Every record type, parsed email-auth records, identified providers, and a composite security grade — in a single JSON document.

Common Use Cases: Migration, Deliverability, Lead Enrichment, Monitoring

1. Pre-migration audit

Before pointing a domain at a new email host or DNS provider, dump the current state so the rollback path is documented:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=acme.com" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
| jq '{
ns,
mx,
spf: .spf.record,
dmarc: .dmarc.record,
email_provider,
dns_provider
}' > pre-migration.json

Run the same call after the cutover and diff the two snapshots. If email_provider stays the same when you expected it to change, you know propagation hasn't completed.

2. Deliverability triage

When a sales team reports "our emails are going to spam", the first three things to check are SPF, DMARC, and DKIM. One curl call surfaces all three plus a grade:

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=$DOMAIN" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
| jq '{grade: .email_security_grade, summary: .email_security_summary,
spf: .spf.grade, dmarc: .dmarc.policy, dkim: .dkim.exists}'

3. Lead enrichment

For B2B sales, the email provider and DNS provider tell you a lot about company size and IT sophistication. A small business on GoDaddy DNS with no DMARC is a very different conversation from an enterprise on Cloudflare with p=reject. Hook the /dns call into the new-lead webhook in your CRM and write email_provider, dns_provider, and email_security_grade onto the lead record. For the broader pipeline pattern, see Lead Enrichment Pipeline with Tech Detection.

4. Infrastructure-change monitoring

Run a daily cron that compares today's MX, NS, and SPF to yesterday's. Any diff triggers a Slack alert. This is how you catch "marketing changed our ESP and broke SPF" before customer support catches it:

#!/bin/bash
# /opt/scripts/dns-watch.sh — daily cron, 0 8 * * *
DOMAIN="yourdomain.com"
OUT="/var/log/dns-watch/$DOMAIN.json"
PREV="${OUT}.prev"

[ -f "$OUT" ] && mv "$OUT" "$PREV"

curl -s "https://detectzestack.p.rapidapi.com/dns?domain=$DOMAIN" \
-H "x-rapidapi-key: $RAPIDAPI_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
| jq '{mx, ns, spf: .spf.record, dmarc: .dmarc.record, grade: .email_security_grade}' \
> "$OUT"

if [ -f "$PREV" ] && ! diff -q "$PREV" "$OUT" > /dev/null; then
DIFF=$(diff -u "$PREV" "$OUT" | head -40)
curl -s -X POST "$SLACK_WEBHOOK" \
-H "Content-Type: application/json" \
-d "{\"text\":\"DNS change detected for $DOMAIN:\n\`\`\`$DIFF\`\`\`\"}"
fi

DNS isn't only an email signal — CDN and hosting providers also leak through. For that angle see Detect CDN & Hosting Provider and DNS-Based Technology Detection.

Pricing and Rate Limits

Plan	Requests/Month	Price	Typical fit
Basic (free)	100	$0/mo	Personal audits, weekly checks on a few domains
Pro	1,000	$9/mo	Small MSP, daily monitoring of 20–30 domains
Ultra	10,000	$29/mo	Lead enrichment at modest volume, agency portfolios
Mega	50,000	$79/mo	Vendor-risk programs, large-scale CRM enrichment

Quota is shared across endpoints: /dns, /analyze, /certificate/check, and /security all draw from the same monthly bucket. A daily check on 3 domains is ~90 requests/month — comfortably inside the free tier.

For SSL alongside DNS monitoring, pair this with the SSL Certificate Check API.

Getting Started in 60 Seconds

Sign up at rapidapi.com/mlugoapx/api/detectzestack and copy your x-rapidapi-key.
Run the curl example above with a domain you control.
Read email_security_grade first — if it's not an A, the rest of the response tells you exactly which protocol pulled it down.
If you only want a smoke test with no signup, hit https://detectzestack.com/demo?url=https://example.com — same response shape (for tech detection), no key needed.

DEV Community: MikeL

Find Companies Using Java: Detection Signals and API

Why Finding Companies Using Java Is Harder Than Front-End Tech

Java Runs on the Server, So Detection Relies on Indirect Signals

Signals That a Website Runs on Java

JSESSIONID Session Cookies

Server and X-Powered-By Headers (Apache Tomcat, Jetty, JBoss/WildFly, Servlet/JSP)

URL Patterns (.jsp, .do, .action, ;jsessionid=)

Framework Traces (Spring, Struts, JSF)

What Doesn't Count as Java: JavaScript Is Unrelated

Which Signals DetectZeStack Matches

Limits of Detecting Java from the Outside

Reverse Proxies, CDNs, and Stripped Headers Hide the Backend

API Example: Detect Java with DetectZeStack

Full Stack Scan with GET /analyze

Yes/No Check with GET /check?tech=Java

Scan a Prospect List with POST /analyze/batch

Compare Java and Non-Java Stacks with POST /compare

Using Java Detection for Lead Lists and Security Audits

Mapping Detected Versions to CPE Identifiers for Vulnerability Checks

FAQ

How can I tell if a website runs on Java?

How do I find a list of companies using Java?

Is JavaScript the same as Java for tech detection?

Why does a Java website not show Java in the scan?

Conclusion: Get Your Free API Key on RapidAPI

Related Reading

Find Companies Using Contentful CMS via API (2026 Guide)

Why Companies Using Contentful Are a Distinct Prospect Segment

Why Contentful Is Harder to Detect Than WordPress

Headless means no generator meta tag and no CMS-rendered HTML

The signals that do survive the build: ctfassets.net and the Contentful API host

The frontend stack sitting in front of Contentful

Check One Domain for Contentful Free (GET /demo)

API Examples: Detecting Contentful Four Ways

GET /check?tech=Contentful — a yes/no answer with confidence

GET /lookup?tech=Contentful — domains already known to run Contentful

POST /analyze/batch — scan up to 10 prospect domains per request

POST /compare — diff a Contentful site against a WordPress competitor

Building a Contentful Prospect List End to End

Tracking Migrations Onto and Off Contentful

Rate Limits, Caching, and What a Contentful Sweep Costs

Accuracy Notes and Known Limits

Get Your API Key and Start Finding Contentful Sites

Related Reading

Find Companies Using Akamai Bot Manager (API Guide)

Why Build a List of Companies Using Akamai Bot Manager

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

The Signals That Reveal Akamai Bot Manager

The Bot Manager Cookies: ak_bmsc, bm_sz, and bm_sv

The Akamai Edge Signals Underneath It

Check One Domain by Hand With curl

Detect Akamai Bot Manager With the DetectZeStack API

The /demo Endpoint, No API Key Required

Single Domain: GET /analyze With Your API Key

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

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

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

Reverse Lookup: Domains Already Known to Run Bot Manager

Comparing Two Sites’ Edge Security Posture With POST /compare

Pricing, Rate Limits, and Getting an API Key

Conclusion and Next Steps

Related Reading

Detect Drupal Website: Manual Checks + API Guide (2026)

Why Detect Drupal? Sales, Security, and Migration Use Cases

Manual Ways to Detect a Drupal Website

Check the X-Generator Header and Meta Generator Tag

Look for /sites/default/ Asset Paths and Drupal Settings JSON

Probe Known Drupal Paths (CHANGELOG.txt, /user/login, /core/)

Why Manual Checks Fail on Hardened or Cached Drupal Sites

Detect Drupal Instantly with the DetectZeStack API

curl Example with GET /analyze and the JSON Response

Checking Drupal Across 1,000 Domains with POST /analyze/batch

Drupal Detection Signals Explained (Headers, HTML, DNS)

Comparing Two Sites' Stacks with POST /compare

Get Your API Key and Start Detecting

Conclusion

Related Reading

Find Companies Using Mailchimp: API Guide (2026)