DEV Community: MikeL

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.

StackShare Alternative: Programmatic Tech Stack Research API

MikeL — Sun, 17 May 2026 14:01:11 +0000

StackShare was the place engineers went to peek at another company’s stack. You typed in a name, got a profile page, and saw the libraries and services that engineering team had decided to publicly share. For a long time it was the closest thing to a public registry of who was running what.

It still has profile pages. What it doesn’t have, in any practical sense, is a programmatic API you can hit from a CRM workflow, a research notebook, or a sales-ops pipeline. The public StackShare API was deprecated, third-party access went quiet, and the experience now is “browse a UI” rather than “loop over a list of domains.” If your job-to-be-done is “tell my software what stack a company is running,” StackShare isn’t the right shape for it anymore.

This guide covers why people end up looking for a StackShare alternative, what a programmatic tech stack research API actually needs to do, and how the tradeoffs shake out across the realistic options. The example at the end is a working curl against a free endpoint — you can run it in 30 seconds and decide for yourself.

Why Look for a StackShare Alternative

Three concrete reasons surface again and again:

No accessible public API. StackShare’s API access has effectively wound down for general developer use. You can browse profiles in a browser, but stitching that data into a workflow means scraping a UI — brittle, slow, and against the terms most public sites set. For a research workflow or a CRM enrichment job, that’s a non-starter.
Crowdsourced data goes stale. Profiles on StackShare are filled in by engineers at the company, often once, often years ago. A team that filed their stack in 2021 might be on a completely different setup now — new framework, different CDN, replaced analytics, dropped feature flags. The profile doesn’t know.
Coverage is patchy. Big-name SaaS companies have profiles. The mid-market SaaS company you’re prospecting into often does not. For sales research and lead enrichment workflows, the long tail is where the value is — and that’s where StackShare thins out the most.

If any of those bites you, what you actually want is a tech detection API: something you give a domain to, and it tells you, right now, what that domain is running. The next sections walk through what StackShare offers, where the gap is, and how a programmatic alternative covers it.

What StackShare Offers (and What’s Missing)

StackShare’s product is a community wiki for tech stacks. Engineers create a profile for their company, list the tools and services they use, and tag categories. The site aggregates those entries into directories — “everyone using Postgres,” “all sites running Stripe,” and so on — and surfaces popularity trends and comparisons between similar tools.

That model has real strengths:

Editorial framing. Profiles include a why, not just a what. Why a team picked PostgreSQL over MySQL, why they switched analytics tools. That context is rare in any other source.
Categories of tools detection alone misses. Internal tools, project management software, CI/CD platforms, design tools — things that don’t leave a fingerprint on the public website. A self-reported profile knows the team uses Linear and GitHub Actions; a website scanner does not.
Discovery and trends. “What are all the alternatives to Segment?” is a question StackShare is genuinely good at, because the data is structured around tools rather than companies.

The API Gap

What StackShare doesn’t do well in 2026 is programmatic access. The public API that existed in earlier years isn’t generally available now, and there’s no documented self-serve replacement aimed at developers who want to enrich a list of 5,000 domains. So the data exists, but it sits behind a UI you have to click through. For workflows where automation is the whole point, that’s the missing piece.

The other gap is freshness. Detection from an actual scan tells you what a website is doing today. A profile that was last updated in 2022 tells you what an engineer remembered to type in three years ago. For competitive intelligence, lead enrichment, and stack monitoring, you need today.

DetectZeStack as a Programmatic StackShare Alternative

DetectZeStack is a focused REST API for live tech stack detection. Give it a domain, get back the technologies running on the public-facing site — JavaScript frameworks, CMS, analytics, CDN, hosting, payment processors, marketing tools, web server, security headers, and more. There’s no community wiki, no profile editing, no UI to curate. The product is the API.

The free tier on RapidAPI is 100 requests/month with no credit card. Paid tiers scale linearly: $9/mo for 1,000 requests, $29/mo for 10,000, $79/mo for 50,000. API access is on every tier — the free tier and the top tier hit the exact same endpoints with the exact same response shape.

Live Detection vs Crowdsourced Profiles

Every /analyze call performs a real scan against the target domain. There’s no static profile to go stale, no cached community entry. If a company switched their CDN from Fastly to Cloudflare last week, the next scan reflects that. If they swapped React for Svelte, the next scan reflects that.

That comes with a tradeoff worth being honest about: detection only sees what’s on the public site. Internal tools, build pipelines, communication apps, ticket trackers — none of those leave fingerprints on a marketing page. A self-reported profile catches them; a scan does not. If your research depends on knowing the internal tools side, detection alone won’t replace it. If your research is “what does this company’s public stack look like, programmatically, at scale,” detection wins clearly.

DNS, SSL, and Security Signals StackShare Doesn’t Cover

DetectZeStack runs three detection layers on every scan, and each detected technology carries a source field of http, dns, or tls so you can tell which layer surfaced it:

HTTP fingerprinting against the open-source Wappalyzer signature database (7,500+ patterns) for frameworks, CMS, analytics, ad tech, marketing automation, server software, and much more. This is the same signature corpus that powers several open-source detection tools, kept current with regular updates.
DNS analysis on CNAME and NS records to identify CDNs and hosting providers that don’t advertise themselves in HTTP headers. CDN and hosting detection via DNS catches Cloudflare in proxy mode, CloudFront, Fastly, Vercel, Netlify, and Akamai even when the upstream Server header is generic.
TLS inspection for certificate authority, HSTS configuration, and TLS-level signals. Useful when an upstream blocks the HTTP fetch but DNS and TLS still produce a partial picture.

None of that exists on a StackShare profile, because none of it is the kind of thing an engineer types into a wiki. It only shows up when you actually scan the domain.

API Example: Pulling a Company’s Tech Stack in One Call

The fastest way to compare a profile-based tool to a detection API is to run the same domain through the API and look at the JSON. The DetectZeStack /demo endpoint requires no authentication, so you can do this with one curl right now:

$ curl -s "https://detectzestack.com/demo?url=stripe.com" | jq

Response (trimmed for length):

{
"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 web-infrastructure and website-security company.",
"website": "https://www.cloudflare.com",
"icon": "Cloudflare.svg",
"source": "dns",
"version": "",
"cpe": ""
},
{
"name": "Stripe",
"categories": ["Payment processors"],
"confidence": 100,
"description": "Stripe is an online payment processing platform for internet businesses.",
"website": "https://stripe.com",
"icon": "Stripe.svg",
"source": "http",
"version": "",
"cpe": ""
}
],
"categories": {
"CDN": ["Cloudflare"],
"JavaScript frameworks": ["React"],
"Payment processors": ["Stripe"]
},
"meta": {
"status_code": 200,
"tech_count": 14,
"scan_depth": "full"
},
"cached": false,
"response_ms": 1842
}

A few things worth pointing out about the response shape:

technologies is the full list. Each entry has a confidence score (0–100) and a source field indicating which detection layer surfaced it. Filter on source: "dns" when you only want infrastructure signals.
categories is a convenience map keyed by category name. Want every payment processor regardless of detection method? Read categories["Payment processors"].
meta.scan_depth is "full" when all three layers ran cleanly. "partial" means HTTP was blocked but DNS and TLS still produced results.
cached and response_ms sit at the top level, not inside meta. First-time scans typically take 1.5–3 seconds; cached scans return in 5–50ms.
cpe is populated for technologies that have a CPE 2.3 identifier in the signature database. Feed those straight into NVD for vulnerability lookups — the kind of CVE pipeline StackShare profiles can’t support.

Once you have an API key, the authenticated endpoint behaves identically:

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

For a research workflow that processes a list of domains, the batch endpoint accepts up to 10 URLs in one request:

$ curl -sX 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": ["stripe.com", "shopify.com", "vercel.com"]}' | jq

If you’re scanning thousands of domains, chunk into batches of 10 and run them concurrently from a worker pool. Scanning a thousand domains in one job covers the rate-limit math and a worker-pool pattern that holds up under real load.

Comparing Two Companies’ Stacks Programmatically

One of the most common StackShare workflows is “show me the difference between these two companies’ stacks.” DetectZeStack exposes that as a single endpoint:

$ curl -sX 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": ["stripe.com", "square.com"]}' | jq

The response groups detected technologies into the ones both domains share, the ones unique to each, and the categorical breakdown. That makes it straightforward to power a “how does our stack compare to a competitor’s” tile in a dashboard, or to scan a target list of competitors weekly and alert when the diff changes. Competitor website technology analysis walks through the full pattern.

For change tracking specifically — the “they used to run X, now they run Y” question — the /changes endpoint returns a feed of detected technology changes from the moment you start scanning a domain regularly. Tracking website tech changes via API covers wiring that into a webhook or a daily digest.

Use Cases: Sales Research, Competitive Intel, and Lead Enrichment

The reasons teams move from “StackShare profiles in a browser” to “detection API in a script” are mostly the same three workflows, in some combination:

Sales research and prospecting. Filter your TAM by what they’re actually running. “Show me every domain in my account list using HubSpot” is a one-liner against the API and a manual click-through against profiles. Technographic prospecting covers the pattern in detail.
CRM enrichment. Fire a webhook on every new account in your CRM, hit /analyze, write the technologies back as fields. The hard part is wiring the data flow; the detection itself is one HTTP call. Tech stack enrichment for sales teams walks through the integration patterns.
Competitive intelligence. Daily scan of a watchlist of competitor domains, surface diffs over time, alert when something material changes. The detection API gives you the raw signal; a change-tracking pipeline makes it actionable.

None of those workflows fit well into a profile-page model. They all assume the data is structured, queryable, and current.

When self-reported still wins: If your research depends on internal tools (project management, CI/CD, communication, design), self-reported profiles are still the better source. A scan can’t see Linear or Notion. The right answer is often both — detection for the public stack, profiles or surveys for the internal layer.

Pricing and Getting Started

Detection-API pricing for tech stack research is published, predictable, and an order of magnitude lower than enterprise sales-intel tools. DetectZeStack’s tiers on RapidAPI:

Tier	Price	Requests / Month	Best For
Basic	$0	100	Trying it, side projects
Pro	$9	1,000	Indie tools, small enrichment jobs
Ultra	$29	10,000	CRM enrichment, dashboards
Mega	$79	50,000	Large account lists, scheduled re-scans

For comparison, full sales-intelligence platforms that bundle detection with contact databases and firmographic data start in the four-figure-per-month range and require a sales call. Technographic data pricing covers why that gap exists across the whole category — the contact data dominates the price, not the detection.

Getting started is one step: sign up on RapidAPI, copy your key, and call /analyze. There’s no procurement process, no annual commit. If you’re still deciding, run the /demo curl above against three or four of the domains you actually care about. The response shape is identical to /analyze — that single call will tell you whether the detection breadth covers your real workflow before you commit to anything.

Conclusion

StackShare is still useful for browsing curated, editorial profiles of well-known engineering teams. What it isn’t, in 2026, is a programmatic source of truth you can plug into automation. For tech stack research that has to scale — CRM enrichment, prospecting, competitive monitoring, change tracking — a live detection API is the right shape.

If you’re evaluating options for that job, the broader landscape is in the 2026 detection API roundup. The free BuiltWith alternatives guide covers the zero-cost end. And the single API call walkthrough shows the integration patterns most teams settle on once they decide.

Set Up Webhook Tech Stack Changes Alerts via API

MikeL — Sun, 10 May 2026 14:00:36 +0000

Polling an API on a timer to check whether a website changed its tech stack is wasteful. You burn requests checking domains that have not changed, and you miss changes that happen between your polling intervals. Webhooks solve both problems: DetectZeStack monitors domains on a schedule and pushes notifications to your server only when something actually changes.

This guide walks through the full webhook lifecycle: creating a subscription, enabling scheduled monitoring, verifying HMAC-signed payloads, and building a working Slack integration that alerts your team when a competitor switches frameworks, adds a CDN, or drops their analytics provider.

Why Monitor Websites for Tech Stack Changes

Technology stack changes are leading indicators. A company adding Stripe is about to launch payments. A competitor switching from Heroku to AWS is preparing to scale. A client removing their Content-Security-Policy header just created a security vulnerability nobody noticed.

Manual checking does not scale. If you are tracking 20 competitor domains, logging in weekly to scan each one is a full hour of repetitive work. And you will miss changes that happen mid-week.

Webhook alerts flip the model: instead of you checking DetectZeStack, DetectZeStack checks the domains and tells you when something changes. Zero wasted effort, zero missed changes.

Use Cases for Webhook Tech Stack Changes Alerts

Competitive intelligence — get notified when a competitor adds Intercom, switches from React to Next.js, or deploys behind Cloudflare
Security monitoring — alert when a managed client removes security headers, drops their WAF, or changes SSL configuration
Sales signals — identify prospects adding payment processors, marketing automation, or analytics tools that indicate buying intent
Investment due diligence — track portfolio company infrastructure decisions in real time rather than waiting for quarterly updates
Agency client oversight — catch unauthorized changes to client websites before they become incidents

How DetectZeStack Webhook Alerts Work

The webhook system has three components:

Subscription — you register a domain + callback URL pair via POST /webhooks
Monitoring — you enable daily or weekly scanning via PATCH /webhooks/{id}
Delivery — when changes are detected, DetectZeStack POSTs a signed payload to your URL

The Webhook Lifecycle

Every time a monitored domain is scanned, DetectZeStack diffs the new snapshot against the previous one. If technologies were added, removed, or changed version, a tech_stack.changed event is sent to all active subscribers for that domain. If nothing changed, no notification is sent — your endpoint stays quiet.

Every scan (whether changes were found or not) also fires a tech_stack.analyzed event with the full technology list. This is useful if you want to log every scan result to your own database regardless of whether anything changed.

Step 1 — Create a Webhook Subscription

curl -X POST "https://detectzestack.p.rapidapi.com/webhooks" \
-H "x-rapidapi-key: YOUR_API_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{
"domain": "competitor.com",
"webhook_url": "https://your-server.com/hooks/techstack"
}'

Response:

{
"id": 42,
"domain": "competitor.com",
"webhook_url": "https://your-server.com/hooks/techstack",
"hmac_secret": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"
}

The hmac_secret is returned exactly once at creation time. Store it securely — it cannot be retrieved again. You will use it to verify that incoming webhook deliveries actually came from DetectZeStack.

Webhook URLs must use HTTPS. HTTP endpoints are rejected to prevent credentials from being transmitted in plaintext. The URL must also resolve to a public IP address (no localhost or private ranges).

Webhook Limits by Plan

Plan	Price	Webhook Subscriptions	Monitoring
Basic (free)	$0/mo	5	Not available
Pro	$9/mo	20	Daily / Weekly
Ultra	$29/mo	50	Daily / Weekly
Mega	$79/mo	100	Daily / Weekly

Free tier users can create webhook subscriptions and receive notifications when they manually trigger scans via the API. Scheduled monitoring (automatic daily or weekly scans) requires a paid tier.

Step 2 — Enable Scheduled Monitoring

Creating a webhook subscription does not automatically start monitoring. To have DetectZeStack scan the domain on a schedule, update the subscription with a monitoring interval:

curl -X PATCH "https://detectzestack.p.rapidapi.com/webhooks/42" \
-H "x-rapidapi-key: YOUR_API_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"monitor_interval": "daily"}'

Response:

{
"status": "updated",
"monitor_interval": "daily"
}

Daily vs Weekly Monitoring Intervals

Choose the interval based on how time-sensitive the information is:

Daily — best for security monitoring, active competitive tracking, or client oversight where you need to catch changes within 24 hours
Weekly — sufficient for investment monitoring, long-term trend tracking, or low-priority domains where day-level granularity is unnecessary

To disable monitoring without deleting the webhook, set monitor_interval to an empty string (""). The subscription remains active for manual triggers but no automatic scans occur.

Step 3 — Receive and Verify Webhook Payloads

When changes are detected, DetectZeStack sends an HTTP POST to your registered URL. The request includes:

Content-Type: application/json
X-Webhook-Event: tech_stack.analyzed
X-Webhook-Signature: sha256=<hex-encoded HMAC>

HMAC Signature Verification

Every delivery is signed with your webhook's HMAC secret using SHA-256. To verify:

Read the raw request body (do not parse JSON first)
Compute HMAC-SHA256 of the raw body using your stored hmac_secret
Compare the computed signature against the value in X-Webhook-Signature (after stripping the sha256= prefix)
Use constant-time comparison to prevent timing attacks

Python verification example:

import hmac
import hashlib

def verify_signature(payload_body: bytes, secret: str, signature_header: str) -> bool:
"""Verify the HMAC-SHA256 signature from DetectZeStack webhook."""
if not signature_header.startswith("sha256="):
return False

expected_sig = signature_header[7:]  # strip "sha256=" prefix
computed = hmac.new(
secret.encode(),
payload_body,
hashlib.sha256
).hexdigest()

return hmac.compare_digest(computed, expected_sig)

Payload Structure

The webhook payload contains the full scan result along with metadata:

{
"event": "tech_stack.analyzed",
"domain": "competitor.com",
"technologies": [
{
"name": "React",
"categories": ["JavaScript frameworks"],
"version": "18.2.0",
"confidence": 100
},
{
"name": "Cloudflare",
"categories": ["CDN"],
"version": "",
"confidence": 100
},
{
"name": "Next.js",
"categories": ["JavaScript frameworks"],
"version": "14.1.0",
"confidence": 100
},
{
"name": "Google Analytics",
"categories": ["Analytics"],
"version": "",
"confidence": 100
}
],
"meta": {
"scan_time_ms": 1842,
"detection_count": 14
},
"timestamp": "2026-04-20T10:30:00Z"
}

If the scan detected changes compared to the previous snapshot, the payload additionally includes technology change events in the /changes feed that you can query separately for structured diffs (added, removed, version_changed).

Delivery retries: If your endpoint returns a non-2xx status code, DetectZeStack retries up to 3 times with exponential backoff (2 seconds, then 4 seconds). After 3 failures, the delivery is abandoned for that event.

Step 4 — Query the Change Feed for Context

Webhook payloads tell you the current state. To see exactly what changed (what was added or removed), query the /changes endpoint:

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

Response:

{
"changes": [
{
"id": 4821,
"domain": "competitor.com",
"technology": "Cloudflare",
"change_type": "added",
"category": "CDN",
"created_at": "2026-04-20T10:30:00Z"
},
{
"id": 4822,
"domain": "competitor.com",
"technology": "Akamai",
"change_type": "removed",
"category": "CDN",
"created_at": "2026-04-20T10:30:00Z"
}
],
"count": 2,
"history_days": 90,
"tier": "pro"
}

Combining webhooks with the change feed gives you the full picture: the webhook tells you something changed, and the change feed tells you exactly what.

Managing Your Webhooks

List Active Webhooks

curl -s "https://detectzestack.p.rapidapi.com/webhooks" \
-H "x-rapidapi-key: YOUR_API_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" | python3 -m json.tool

Response:

{
"webhooks": [
{
"id": 42,
"domain": "competitor.com",
"webhook_url": "https://your-server.com/hooks/techstack",
"monitor_interval": "daily",
"created_at": "2026-04-20T09:00:00Z"
}
],
"count": 1
}

Update or Delete a Webhook

Change the monitoring interval:

curl -X PATCH "https://detectzestack.p.rapidapi.com/webhooks/42" \
-H "x-rapidapi-key: YOUR_API_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"monitor_interval": "weekly"}'

Delete a subscription entirely:

curl -X DELETE "https://detectzestack.p.rapidapi.com/webhooks/42" \
-H "x-rapidapi-key: YOUR_API_KEY" \
-H "x-rapidapi-host: detectzestack.p.rapidapi.com"

Deleting a webhook stops all monitoring and future deliveries for that subscription immediately.

Full Python Example — Slack Alerts on Tech Stack Changes

Here is a complete Flask application that receives DetectZeStack webhooks, verifies the signature, queries the change feed for context, and posts a formatted message to Slack:

import hmac
import hashlib
import requests
from flask import Flask, request, jsonify

app = Flask(__name__)

WEBHOOK_SECRET = "your_hmac_secret_from_creation"
RAPIDAPI_KEY = "YOUR_API_KEY"
SLACK_WEBHOOK = "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

@app.route("/hooks/techstack", methods=["POST"])
def handle_webhook():
# Step 1: Verify signature
signature = request.headers.get("X-Webhook-Signature", "")
if not verify_signature(request.data, WEBHOOK_SECRET, signature):
return jsonify({"error": "invalid signature"}), 401

payload = request.json
domain = payload["domain"]

# Step 2: Query the change feed for structured diffs
headers = {
"x-rapidapi-key": RAPIDAPI_KEY,
"x-rapidapi-host": "detectzestack.p.rapidapi.com"
}
resp = requests.get(
f"https://detectzestack.p.rapidapi.com/changes?domain={domain}",
headers=headers
)
changes = resp.json()

if changes["count"] == 0:
return jsonify({"status": "no changes"}), 200

# Step 3: Format and send Slack message
lines = []
for c in changes["changes"]:
prefix = {"added": "+", "removed": "-", "version_changed": "~"}
symbol = prefix.get(c["change_type"], "?")
line = f"[{symbol}] {c['technology']} ({c['category']})"
if c.get("previous_version") and c.get("new_version"):
line += f" {c['previous_version']} -> {c['new_version']}"
lines.append(line)

message = f"*Tech stack change detected on {domain}:*\n```
{% endraw %}
\n"
message += "\n".join(lines[:10])  # limit to 10 changes
message += "\n
{% raw %}
```"

requests.post(SLACK_WEBHOOK, json={"text": message})
return jsonify({"status": "ok"}), 200

def verify_signature(payload_body, secret, signature_header):
if not signature_header.startswith("sha256="):
return False
expected = signature_header[7:]
computed = hmac.new(
secret.encode(), payload_body, hashlib.sha256
).hexdigest()
return hmac.compare_digest(computed, expected)

if __name__ == "__main__":
app.run(port=5000)

Deploy this behind HTTPS (using nginx, Caddy, or a platform like Railway) and register the public URL as your webhook endpoint. The entire pipeline — detection, notification, and alerting — runs automatically without any polling or cron jobs on your side.

Try It: Scan a Domain with the Demo Endpoint

Before setting up webhooks, verify what DetectZeStack detects for a given domain using the free demo endpoint (no API key required):

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

This returns the full technology list for stripe.com — the same data structure that webhook payloads use. Use this to validate that the domains you plan to monitor produce useful detection results before investing in webhook setup.

Webhook Limits and Tier Comparison

Feature	Free	Pro ($9/mo)	Ultra ($29/mo)	Mega ($79/mo)
Webhook subscriptions	5	20	50	100
Scheduled monitoring	No	Daily / Weekly	Daily / Weekly	Daily / Weekly
Change history depth	7 days	30 days	90 days	365 days
API requests/month	100	1,000	10,000	50,000
HMAC-signed payloads	Yes	Yes	Yes	Yes
Retry on failure	3 attempts	3 attempts	3 attempts	3 attempts

All plans include HMAC signature verification and automatic retry with exponential backoff. The difference between tiers is how many domains you can monitor simultaneously and whether scheduled (automatic) monitoring is available.

Get Started with Webhook Tech Stack Changes Alerts

Setting up webhook-based tech stack monitoring takes about five minutes:

Get your API key from RapidAPI (free tier includes 5 webhook subscriptions)
Create a subscription with POST /webhooks for each domain you want to monitor
Enable scheduled monitoring with PATCH /webhooks/{id} (paid tiers)
Implement signature verification in your webhook handler
Route notifications to Slack, PagerDuty, email, or your own dashboard

No polling. No cron jobs. No wasted API requests checking domains that have not changed. DetectZeStack handles the scanning, diffing, and notification delivery — you just receive the alerts.

WhatRuns Alternative API: 4 Options for Programmatic Detection

MikeL — Fri, 01 May 2026 14:01:10 +0000

If you opened this page, you probably went looking for “WhatRuns API” or “WhatRuns API key,” hit a dead end, and started searching for an alternative. That’s the right move—WhatRuns has no public API, no key, and no documentation. It is a browser extension, full stop.

The good news is that the use cases people associate with WhatRuns—identifying JavaScript frameworks, spotting CMS platforms, mapping hosting and CDN providers, enriching lead lists—are well covered by APIs you can hit with curl in a few seconds. This guide walks through four practical WhatRuns alternative API options, the trade-offs between them, and a working example you can copy and run today.

Why WhatRuns Has No Public API

WhatRuns’ founder shipped the extension as a free product several years ago and effectively walked away from active development. The extension still works as a manual lookup tool, but the team never published a REST endpoint, never released SDKs, and never documented an authentication flow. The detection logic runs inside the browser, reads page-level signals, and reports back to a private backend the extension uses for its own UI—not for third-party consumption.

The result: any workflow that needs automated, repeatable tech detection has to look elsewhere. Browser extensions also can’t see the infrastructure layer. They can’t resolve DNS, inspect TLS certificates, or check IP ranges, which means a CDN like CloudFront or Fastly that doesn’t advertise itself in HTTP headers is invisible. A purpose-built API can see all four layers, which matters once you start scanning anything beyond a marketing site.

What to Look for in a WhatRuns Alternative API

Not every detection API solves the same problem. Before picking one, decide what you actually need. Three dimensions matter most.

Coverage Across JS, CMS, Hosting, and DNS

WhatRuns is strongest at JavaScript framework and front-end library detection—it surfaces React, Vue, Next.js, jQuery, Tailwind, analytics scripts, and chat widgets reliably. A direct replacement should cover the same categories, plus the infrastructure signals the extension misses. At a minimum, look for:

JavaScript frameworks and libraries — React, Vue, Angular, Next.js, Svelte, jQuery, Tailwind CSS, and so on.
CMS and e-commerce platforms — WordPress, Shopify, Webflow, HubSpot CMS, Drupal, Magento, Squarespace.
Analytics and marketing tools — Google Analytics, Segment, Mixpanel, Amplitude, HubSpot, Intercom.
Hosting and CDN — Cloudflare, CloudFront, Fastly, Vercel, Netlify, Akamai. DNS-level detection is what separates the API class from the extension class.
Security and TLS — HSTS, certificate authority, SSL/TLS configuration.

Pricing That Scales With Usage

If you’re scanning ten domains a month, a free tier on RapidAPI is fine. If you’re enriching a 50,000-row CRM export, the per-domain cost dominates. The cheapest providers settle around $9–$29/month for a few thousand requests. The expensive end—BuiltWith’s premium tier—starts at $295/month and is priced for enterprise sales intelligence rather than ad-hoc detection. Technographic data pricing varies by an order of magnitude, so check the rate limits and price-per-call before committing.

Response Latency and Cache Behavior

A first-time scan of an unfamiliar domain usually costs 1.5–3 seconds because the API has to make an outbound HTTP request, parse the response, run DNS lookups, and complete a TLS handshake. Subsequent scans of the same domain should be near-instant if the provider caches results. Cached responses on DetectZeStack typically return in 5–50ms, which matters when you’re fanning out across hundreds of domains in a job.

Four WhatRuns Alternative APIs Compared

Here are the four credible options, ordered roughly from easiest-to-start to most-effort-to-run.

DetectZeStack

DetectZeStack is a REST API for tech stack detection that combines HTTP fingerprinting (using the Wappalyzer signature database with 7,300+ patterns), DNS CNAME and NS analysis, and TLS certificate inspection. The free tier is 100 requests/month on RapidAPI with no credit card. Paid tiers start at $9/month for 1,000 requests and scale to 50,000 requests at $79/month.

Endpoints worth knowing about:

GET /analyze — single URL, full detection across HTTP, DNS, and TLS.
GET /demo — same response shape as /analyze, no API key needed, useful for trying it out.
POST /analyze/batch — up to 10 URLs per request for parallel scans.
POST /compare — diff two domains to see which technologies are unique to each.
GET /certificate — TLS certificate details (issuer, expiry, SANs).
GET /dns — raw DNS records (A, AAAA, CNAME, MX, NS, TXT).

Strengths: free tier, no credit card, DNS-layer detection that browser extensions can’t do, version numbers and CPE identifiers when available for vulnerability mapping. Honest weaknesses: smaller historical dataset than BuiltWith’s, no built-in lead-list export.

BuiltWith API

BuiltWith is the long-running incumbent. Their detection covers a similar range of categories and includes deep historical data that goes back years—useful if you want to know when a domain switched from Magento to Shopify. The catch is pricing: the entry-level “Basic” API plan starts at $295/month, with higher tiers running into the low four figures. If your use case is sales intelligence on a known list of accounts, the historical depth can pay for itself. For ad-hoc developer use, it’s usually overkill. BuiltWith versus WhatRuns covers the deeper comparison.

Wappalyzer API

Wappalyzer publishes its detection signatures as open source (MIT license) and runs a paid hosted API on top of them. Pricing starts at around $250/month for the “Lookup” plan with monthly request quotas. The signature database is the same one that powers DetectZeStack and many other tools, so detection breadth is comparable. Wappalyzer’s differentiator is the bundled lead-generation tooling (filtered lists of sites by technology, exportable to CSV).

Self-Hosted wappalyzergo

If you have engineering capacity and want zero per-call cost, you can run detection in-process. wappalyzergo is a Go library that ports the Wappalyzer detection logic and ships the same signature JSON. You write a few lines of Go to fetch a URL, hand the response to the library, and read out the technologies. There’s no rate limit, no monthly bill, and no third-party dependency in the request path.

The trade-offs are real, though. You need to maintain the deployment, update the signature file periodically, build outbound fetch logic with proper SSRF protection, and handle DNS and TLS detection separately because wappalyzergo only handles HTTP-layer detection. A deeper walkthrough of the open-source path covers what to expect in production. This is the right answer when you’re scanning millions of domains and the API bills would be prohibitive; it’s the wrong answer for most teams who just want a result back from one HTTP call.

Option	Free Tier	Entry Price	DNS / TLS Detection	Hosted
DetectZeStack	100 req/mo	$9/mo (1k req)	Yes	Yes
BuiltWith API	No	$295/mo	Yes	Yes
Wappalyzer API	No	$250/mo	Partial	Yes
wappalyzergo (self-hosted)	Free (your infra)	$0	Build it yourself	No

Calling the DetectZeStack API: A Working Example

The fastest way to see whether a detection API meets your needs is to fire one request at it. The DetectZeStack /demo endpoint requires no authentication, so you can test the response shape before signing up for anything.

Single-URL Detection With /analyze

Try /demo first. Same response shape as /analyze, no key needed:

$ curl -s "https://detectzestack.com/demo?url=stripe.com" | jq

Response (trimmed):

{
"url": "https://stripe.com",
"domain": "stripe.com",
"technologies": [
{
"name": "Amazon S3",
"categories": ["CDN"],
"confidence": 100,
"description": "Amazon S3 or Amazon Simple Storage Service is a service offered by AWS that provides object storage through a web service interface.",
"website": "https://aws.amazon.com/s3/",
"icon": "Amazon S3.svg",
"source": "http",
"version": "",
"cpe": ""
},
{
"name": "Nginx",
"categories": ["Web servers", "Reverse proxies"],
"confidence": 100,
"description": "Nginx is a web server that can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.",
"website": "https://nginx.org/en",
"icon": "Nginx.svg",
"cpe": "cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*",
"source": "http",
"version": ""
},
{
"name": "DigiCert",
"categories": ["SSL/TLS certificate authority"],
"confidence": 70,
"source": "tls"
}
],
"categories": {
"CDN": ["Amazon S3"],
"PaaS": ["Amazon Web Services"],
"Reverse proxies": ["Nginx"],
"SSL/TLS certificate authority": ["DigiCert"],
"Security": ["HSTS"],
"Web servers": ["Nginx"]
},
"meta": {
"status_code": 200,
"tech_count": 5,
"scan_depth": "full"
},
"cached": false,
"response_ms": 1842
}

A few things worth noting in the response:

technologies is the full list with confidence scores and source labels. The source field shows how the technology was detected: http for header or HTML pattern matches, dns for CNAME/NS matches, and tls for certificate-based detection.
categories is a convenience map for “give me everything in CDN” or “give me everything in JavaScript frameworks.”
meta.scan_depth is "full" when all three layers ran, "partial" when the upstream blocked HTTP requests but DNS or TLS still produced results.
cached and response_ms sit at the top level, not inside meta. Cached responses typically return in 5–50ms.
cpe is populated when a CPE 2.3 identifier exists for the technology, which is what you feed into NVD for vulnerability lookups.

Once you have an API key, the same call against the authenticated endpoint looks like:

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

Bulk Scans With /analyze/batch

For workflows that need to scan a list of domains, POST /analyze/batch handles up to 10 URLs per request and runs the fetches in parallel server-side. That removes the round-trip overhead of issuing ten separate calls.

$ curl -sX 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": ["stripe.com", "shopify.com", "vercel.com"]}' | jq

The response is a results array with one entry per input URL:

{
"results": [
{ "url": "stripe.com",  "result": { "domain": "stripe.com", "technologies": [...], "categories": {...}, "meta": {...}, "cached": false, "response_ms": 1842 } },
{ "url": "shopify.com", "result": { "domain": "shopify.com", "technologies": [...], "categories": {...}, "meta": {...}, "cached": true,  "response_ms": 12 } },
{ "url": "vercel.com",  "result": { "domain": "vercel.com", "technologies": [...], "categories": {...}, "meta": {...}, "cached": false, "response_ms": 1654 } }
],
"total_ms": 1873,
"successful": 3,
"failed": 0
}

If a single URL in the batch fails (for example, an unreachable domain), the corresponding entry will have an error field instead of a result field. The successful items still come through, so a partial failure doesn’t blow up the whole job. For larger lists, chunk into batches of 10 and run them concurrently from your worker pool. Scanning a thousand domains covers the rate-limit math in detail.

Migrating From the WhatRuns Extension to an API Workflow

If you’ve been using WhatRuns by hand—clicking the icon on each page you visit—moving to an API is mostly a rewiring exercise. The shape of the data is similar; what changes is the integration point. A few practical migration tips:

Map your existing categories. WhatRuns groups results into “Frameworks,” “Analytics,” “CMS,” “Web Server,” etc. DetectZeStack uses Wappalyzer’s category names, which are similar but not identical. The categories object in the response is your lookup table.
Trust confidence scores. WhatRuns shows a single technology name with no confidence indicator. APIs return a 0–100 score per detection. For batch jobs, filtering at confidence >= 80 usually removes most false positives without sacrificing real matches.
Pull DNS and TLS results explicitly. If you specifically need CDN or hosting provider, don’t rely on the HTTP detection alone—Cloudflare in proxy mode or CloudFront without identifying headers will only show up via DNS or TLS signals. Filter technologies by source: "dns" or source: "tls" when you want infrastructure signals only.
Cache aggressively. The API caches responses, but if you’re running daily enrichment over a static account list, store the results in your own warehouse and only refresh weekly. The cached field tells you whether the response came from cache.
Track changes over time. The big upside of moving to an API is that you can record results and diff them. Tracking technology changes over time is something WhatRuns simply can’t do because it has no concept of history.

Picking the right tier: If you’re scanning 10–100 domains a month, the free tier covers it. If you’re enriching a CRM with thousands of accounts, the $29/month tier (10,000 requests) is usually the sweet spot. The $79/month tier (50,000 requests) makes sense when you’re running scheduled re-scans across a large account list.

Get Started With a Free API Key

WhatRuns won’t ever ship an API—the project is dormant. But the workflows people associate with WhatRuns translate directly to a detection API, and once you make the switch you get capabilities the extension was structurally incapable of: DNS-layer detection, TLS inspection, batch scans, change tracking, and version-level metadata for vulnerability work.

If you want to try the closest behavioral match before committing, run the /demo curl above. It returns the same response shape as the authenticated /analyze endpoint, costs nothing, and will tell you in one round-trip whether the detection breadth is enough for your use case. For deeper comparisons, see DetectZeStack vs WhatRuns and the broader 2026 detection API landscape. To see the full single-call workflow end-to-end, the single API call walkthrough covers the integration patterns most teams settle on.

Ecommerce Tech Stack Analysis: Shopify vs WooCommerce

MikeL — Thu, 23 Apr 2026 14:01:03 +0000

Every ecommerce store is built on layers of technology: a platform, a payment processor, a CDN, analytics tools, marketing integrations, and often a JavaScript framework powering the storefront. Understanding what those layers are—and how they differ between competitors—is valuable for sales teams qualifying leads, agencies scoping migration projects, and researchers mapping market trends.

This guide breaks down the typical tech stacks behind Shopify and WooCommerce stores, explains how to identify custom-built ecommerce platforms, and shows how to automate the analysis using the DetectZeStack API. If you have worked through our Shopify vs WooCommerce detection guide, this post goes deeper: beyond just identifying the platform, we analyze the full stack surrounding it.

Why Ecommerce Tech Stack Analysis Matters

Knowing that a store runs on Shopify tells you one thing. Knowing that it also uses Stripe for payments, Cloudflare for its CDN, Klaviyo for email, and Google Analytics 4 for tracking tells you far more. Here are the practical use cases:

Sales prospecting — A WooCommerce store without a dedicated hosting provider is a prospect for managed WordPress hosting. A Shopify store still using Google Analytics Universal (instead of GA4) may need an analytics migration partner. Technographic prospecting turns technology signals into qualified leads.
Competitive intelligence — Map every competitor in a niche to see which payment processors dominate, which CDNs are most common, and whether the market is consolidating around Shopify or staying on WooCommerce. See our competitor tech analysis guide for the full methodology.
Migration planning — Agencies migrating stores from WooCommerce to Shopify (or vice versa) need to inventory every plugin, integration, and third-party script before quoting a project. Missing a critical integration means scope creep.
Security auditing — Outdated jQuery versions, exposed PHP headers, and missing security headers are all signals that a technology detection scan can surface. WooCommerce stores in particular inherit the security posture of their hosting environment.

What a Typical Shopify Tech Stack Looks Like

Shopify is a hosted platform, which means the core infrastructure is managed by Shopify itself. But the technology stack of a Shopify store extends well beyond the platform. Here is what a scan of a typical Shopify store reveals:

Platform: Shopify (detected via DNS CNAME to shops.myshopify.com and cdn.shopify.com script references)
CDN: Shopify CDN for assets, often with Cloudflare or Fastly in front for the storefront domain
Payment: Stripe (Shopify Payments is built on Stripe), detected via js.stripe.com script inclusion
Analytics: Google Analytics, often alongside Shopify’s built-in analytics
JavaScript: jQuery (still common in Shopify themes), React (for Hydrogen/headless storefronts)
Marketing: Meta Pixel, Google Tag Manager, Klaviyo

Payment, CDN, and Analytics on Shopify

Shopify Payments—used by the majority of Shopify stores—is powered by Stripe under the hood. When you scan a Shopify store, you will often see both “Shopify” and “Stripe” in the results. The Stripe detection comes from the js.stripe.com/v3 script tag that Shopify injects into checkout pages.

For CDN, Shopify serves static assets (images, CSS, JavaScript) from cdn.shopify.com, which is its own CDN infrastructure. However, many Shopify merchants also use Cloudflare as a reverse proxy in front of their custom domain. In DNS terms, you will see the custom domain CNAME pointing to shops.myshopify.com, but the nameservers may be Cloudflare’s *.ns.cloudflare.com. DetectZeStack catches both signals: the Shopify CNAME via DNS detection and the Cloudflare nameservers via NS record inspection.

Google Analytics is present on the vast majority of Shopify stores. Detection is straightforward: the gtag.js script or the G- measurement ID in the page source. Many stores also load Google Tag Manager, which acts as a container for additional tracking scripts.

What a Typical WooCommerce Tech Stack Looks Like

WooCommerce is a WordPress plugin, so every WooCommerce store is also a WordPress site. This means the tech stack is more varied than Shopify’s because the store owner (or their hosting provider) makes every infrastructure decision.

Platform: WordPress + WooCommerce (detected via /wp-content/ paths, X-Powered-By: PHP header, and WooCommerce-specific meta tags)
Hosting: Varies widely—from shared hosting to managed WordPress hosts to cloud infrastructure on AWS or DigitalOcean
CDN: Cloudflare (most common), CloudFront, or a WordPress-specific CDN
Payment: Stripe, PayPal, or both—installed as WooCommerce payment gateway plugins
Analytics: Google Analytics (via plugin), sometimes with additional tools like Hotjar or Microsoft Clarity
JavaScript: jQuery (WordPress ships it by default), sometimes React (for Gutenberg blocks)
Security: Wordfence or Sucuri (common WordPress security plugins), Let’s Encrypt TLS certificates

Hosting, Plugins, and Performance Layers

The biggest difference between Shopify and WooCommerce stacks is infrastructure ownership. Shopify handles hosting, scaling, and CDN automatically. WooCommerce store owners must choose and configure each layer themselves.

This means WooCommerce stores show far more variety in their tech stacks. A scan might reveal Cloudflare CDN on one store, CloudFront on another, and no CDN at all on a third. You can detect the CDN and hosting provider using DNS CNAME records and HTTP headers, which DetectZeStack checks automatically.

For payment detection, WooCommerce stores typically load Stripe.js or PayPal’s SDK directly on the checkout page. These are detected through HTML script tag analysis. Because WooCommerce is open-source, stores sometimes use less common payment gateways that are harder to detect—but the major processors (Stripe, PayPal, Square) all have well-known JavaScript fingerprints.

Detection tip: If you want to confirm WooCommerce specifically (not just WordPress), check for WordPress detection signals first, then look for WooCommerce-specific indicators: the woocommerce body class, /wp-json/wc/ REST API routes, or wc- prefixed cookies.

Custom-Built Ecommerce Stacks and How to Identify Them

Not every online store runs on Shopify or WooCommerce. Large retailers, marketplaces, and niche platforms often build custom ecommerce systems or use platforms like Magento, BigCommerce, or Salesforce Commerce Cloud.

Custom-built stores are identifiable by what is absent from a scan: no Shopify DNS signatures, no WordPress/WooCommerce fingerprints, no known platform patterns. What you will find instead are the surrounding technologies: the CDN, the JavaScript framework powering the frontend (often React or Next.js—see our Next.js detection guide), the payment processor, and the analytics tools.

BigCommerce stores are detectable via DNS: they CNAME to *.mybigcommerce.com. Magento stores leave HTTP header fingerprints and distinctive HTML patterns. For platforms without strong fingerprints, the surrounding technologies often tell the story. A site running Next.js on Vercel with Stripe checkout and Algolia search is almost certainly a headless commerce implementation, even if the specific backend platform is opaque.

Platform	Primary Detection Signal	Common Companion Technologies
Shopify	CNAME: shops.myshopify.com	Stripe, Cloudflare, Google Analytics, jQuery
WooCommerce	/wp-content/, X-Powered-By: PHP	WordPress, Stripe, PayPal, Cloudflare, jQuery
BigCommerce	CNAME: *.mybigcommerce.com	Cloudflare, Google Analytics, Stripe
Magento	Mage cookies, /static/frontend/ paths	PHP, MySQL, Varnish, Fastly, PayPal
Custom / Headless	No known platform fingerprint	React, Next.js, Vercel, Stripe, Algolia

How to Analyze Any Ecommerce Tech Stack with the DetectZeStack API

Manual inspection with dig, curl, and browser dev tools works for one-off checks, but it does not scale. The DetectZeStack API combines DNS resolution, HTTP header analysis, HTML fingerprinting, and TLS certificate inspection into a single request.

Single-Store Analysis with GET /analyze

To analyze one store, use the free demo endpoint (no API key required, rate-limited to 20 requests per hour):

$ curl -s "https://detectzestack.com/demo?url=allbirds.com" | jq '.technologies[] | {name, categories, confidence}'
{
"name": "Shopify",
"categories": ["Ecommerce"],
"confidence": 100
}
{
"name": "Cloudflare",
"categories": ["CDN"],
"confidence": 80
}
{
"name": "Google Analytics",
"categories": ["Analytics"],
"confidence": 100
}
{
"name": "Stripe",
"categories": ["Payment processors"],
"confidence": 100
}

For production use with higher rate limits, use the authenticated GET /analyze endpoint via RapidAPI:

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

The response includes every detected technology with its name, categories, and confidence score. Confidence reflects the detection method: 100% for direct HTTP/HTML matches, 80% for DNS CNAME matches, 70% for TLS certificate matches.

Comparing Two Stores Side by Side with POST /compare

To compare a Shopify store against a WooCommerce store, use the POST /compare endpoint:

$ 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": ["allbirds.com", "underarmour.com"]}' | jq '.'

The comparison response shows which technologies are shared between the two stores and which are unique to each. This is useful for competitive analysis: if a competitor uses a tool you do not, it may be worth investigating. If two stores in the same market use completely different stacks, that tells you there is no consensus on the “right” approach—an insight that matters for agencies advising clients.

Key Technologies to Watch in Ecommerce Stacks

When analyzing ecommerce tech stacks, certain technologies carry more strategic weight than others. Here is what to pay attention to:

Payment processor — Stripe vs PayPal vs native platform payments. Stripe dominance in a market segment signals developer-oriented stores. PayPal presence often indicates a more traditional retail audience.
CDN choice — Cloudflare is the most common CDN across both Shopify and WooCommerce stores. CloudFront indicates AWS infrastructure. No CDN at all on a WooCommerce store is a red flag for performance. See our CDN detection guide for the technical details.
Analytics tools — Google Analytics is nearly universal, but the presence of additional tools like Hotjar (session recording), Mixpanel (product analytics), or Segment (data pipeline) indicates a more sophisticated operation.
JavaScript framework — jQuery is still the default on most Shopify themes and WordPress sites. React or Vue.js in a store’s stack often means a headless architecture or a custom-built storefront. You can detect JavaScript frameworks through HTML fingerprints and JavaScript global variables.
Security posture — The TLS certificate issuer, the presence of security headers, and the server software version all provide signals. Shopify handles this automatically. WooCommerce stores vary widely, making security posture a useful differentiator.

Scaling Ecommerce Tech Stack Analysis to Hundreds of Sites

Analyzing one or two competitors is useful. Analyzing every store in a market segment is transformative. The POST /analyze/batch endpoint accepts up to 10 URLs per request, letting you scan 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": ["store1.com", "store2.com", "store3.com"]}'

For a detailed walkthrough of scanning hundreds or thousands of domains—including a Python script with rate limiting and CSV output—see How to Batch Scan 1,000 Websites for Tech Stack Data.

At scale, patterns emerge that are invisible at the single-store level. You might discover that 70% of stores in a niche use Shopify, that Stripe is the payment processor for 85% of them, or that stores using Cloudflare CDN have measurably faster response times. This kind of data powers market research reports, competitive strategy, and sales targeting.

Tip: Combine batch scanning with the GET /check endpoint to filter results. For example, after scanning 500 ecommerce domains, use /check?url=store.com&tech=Stripe to quickly verify which stores use Stripe without re-scanning the full tech stack.

Conclusion

Ecommerce tech stack analysis goes beyond knowing whether a store uses Shopify or WooCommerce. The full picture—payment processors, CDNs, analytics tools, JavaScript frameworks, and security posture—reveals actionable intelligence for sales, competitive research, and migration planning.

Shopify stores share a common infrastructure foundation but vary in their third-party integrations. WooCommerce stores vary at every layer, from hosting to CDN to payment gateway. Custom-built stores are identifiable by their surrounding technologies even when the platform itself leaves no fingerprint.

The DetectZeStack API lets you automate this analysis across one store or thousands, returning structured data that you can filter, compare, and integrate into your workflows.

How to Detect if a Website Uses React: 4 Proven Methods

MikeL — Wed, 15 Apr 2026 22:11:22 +0000

React powers a massive share of the modern web. From single-page apps to server-rendered sites built with Next.js, React’s footprint is everywhere—but not always obvious. A well-built React site can look indistinguishable from any other website in the browser. There’s no “Built with React” badge in the footer.

Whether you’re evaluating a competitor’s technology choices, auditing a site for known React vulnerabilities, qualifying leads based on their tech stack, or simply curious about how a product is built, you need reliable detection methods. This guide covers four approaches, from quick manual checks to fully automated API-based detection.

Why Detect React on a Website

Knowing whether a site runs React is more than trivia. Here are the practical reasons people look for this information:

Competitive intelligence: Understanding what frameworks your competitors chose—and whether they use plain React, Next.js, or Gatsby—reveals their engineering priorities. A Next.js site signals investment in SEO and performance. A client-side React SPA suggests a different set of trade-offs.
Security auditing: React versions have known CVEs. Detecting an outdated React version on a target site is a concrete security finding. The same applies to Next.js, which has had its own set of vulnerabilities.
Sales prospecting: If you sell developer tools, monitoring services, or React-specific products, knowing which companies use React determines whether your outreach is relevant. This is the same logic behind finding companies that use Stripe for payment-related prospecting.
Migration planning: Before migrating from Angular to React, or upgrading from React 17 to React 18, you need to know exactly what’s running in production—not what the internal documentation says.
Hiring context: Researching a company’s tech stack before an interview helps you understand what you’ll be working with and what questions to expect.

Method 1 — Browser DevTools Console

The fastest way to check if a website uses React is through the browser’s DevTools console. React leaves several fingerprints in the DOM and in JavaScript globals that you can query directly.

Check for React Global Objects

Open Chrome DevTools (press F12 or Cmd+Option+I on macOS), switch to the Console tab, and run these checks:

// Check for the React DevTools hook (present on most React sites)
!!window.__REACT_DEVTOOLS_GLOBAL_HOOK__

// Check for React Fiber on the root element
!!document.querySelector('#root')?._reactRootContainer

// Check for the data-reactroot attribute (React 15-16 pattern)
!!document.querySelector('[data-reactroot]')

// Check for Next.js (built on React)
!!document.getElementById('__next')

If any of these return true, the site is running React. The __REACT_DEVTOOLS_GLOBAL_HOOK__ check is the most reliable for modern React apps because React itself injects this hook during initialization, regardless of whether React DevTools is installed.

Inspect the DOM for React Fiber Attributes

React’s reconciler (Fiber) attaches internal properties to DOM nodes. In the Elements panel, select any element inside the React app and look at its properties in the Console:

// Select an element, then run:
$0.__reactFiber$   // React 18+
$0.__reactInternalInstance$   // React 16-17
$0._reactInternalFiber   // Older React versions

These properties are prefixed with a random hash (e.g., __reactFiber$abc123), so you may need to type the prefix and let autocomplete show the full property name. If any of these properties exist on DOM nodes, React is managing that part of the page.

Partial React usage: Some sites use React for only part of the page—a checkout widget, a search bar, or a dashboard embedded in a server-rendered page. In these cases, the React root may not be the top-level #root div. Check multiple elements if the top-level checks return false.

Method 2 — View Page Source Clues

Viewing the HTML source (Ctrl+U or Cmd+Option+U) reveals patterns that indicate React, even before JavaScript executes.

Script Tags and Bundle Filenames

React apps typically load bundled JavaScript files. Look for these patterns in the source:

react.production.min.js or react-dom.production.min.js — Direct React library references, common on CDN-loaded setups.
Webpack chunk filenames like main.abc123.js or static/js/bundle.js — While not React-specific, these are the default output of Create React App.
/__next/ prefixed asset paths — A definitive Next.js marker. All static assets in Next.js are served from /_next/static/.

For client-side rendered React apps, the HTML source is often minimal—just a <div id="root"></div> and script tags. This “empty shell” pattern is itself a strong signal of a client-side React SPA, though other frameworks like Vue and Angular can produce similar output.

Server-Side Rendered React and Next.js Markers

Server-rendered React sites (using Next.js, Remix, or custom SSR) include the full HTML content in the source. The distinguishing markers are:

<div id="__next"> — The root element for Next.js applications.
<script id="__NEXT_DATA__" type="application/json"> — Contains the serialized page props, build ID, and routing data. This is the single most reliable indicator of Next.js.
data-reactroot attribute on the root element — Added by ReactDOMServer.renderToString() in React 15-16.
data-nhead or data-react-helmet attributes — Present when using helmet-style head management in React SSR.

<!-- Next.js fingerprint in page source -->
<div id="__next">
<!-- Full server-rendered HTML here -->
</div>
<script id="__NEXT_DATA__" type="application/json">
{"props":{"pageProps":{}},"page":"/","buildId":"abc123"}
</script>

Method 3 — Browser Extensions

React Developer Tools Extension

The official React Developer Tools extension (available for Chrome and Firefox) is the most definitive manual check. When you visit a React-powered site, the extension icon lights up—blue for production builds, red for development builds. It also adds “Components” and “Profiler” tabs to DevTools, letting you inspect the React component tree directly.

The extension works by detecting the __REACT_DEVTOOLS_GLOBAL_HOOK__ that React attaches during initialization. If React is present anywhere on the page—even in a small embedded widget—the extension will detect it.

The limitation: you have to visit each site individually. This is fine for one-off checks but impractical if you need to scan hundreds of sites.

DetectZeStack Chrome Extension

The DetectZeStack Chrome extension detects not just React but the entire technology stack—frameworks, CDNs, analytics tools, hosting providers, and more—all from a single toolbar click. Unlike React DevTools, which only identifies React, DetectZeStack shows the full picture: whether the site also uses Next.js, what CDN or hosting provider serves it, what analytics and marketing tools are loaded, and more.

Method 4 — DetectZeStack API (Programmatic Detection)

Manual methods work for spot checks. When you need to detect React across tens, hundreds, or thousands of sites—for lead qualification, competitive analysis, or security scanning—you need an API.

Single-URL Analysis with curl

The DetectZeStack API detects React and 7,300+ other technologies in a single request. Here is a quick check using the free demo endpoint (no API key required):

$ curl -s "https://detectzestack.com/demo?url=netflix.com" | jq '.technologies[] | select(.name == "React" or .name == "Next.js")'

For production use with higher limits, use the RapidAPI endpoint:

$ curl -s "https://detectzestack.p.rapidapi.com/analyze?url=netflix.com" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
| jq '.technologies[] | select(.categories[] | contains("JavaScript frameworks"))'

Reading the API Response

The API returns a JSON object with all detected technologies. Here is what a React detection looks like in the response:

{
"url": "https://netflix.com",
"domain": "netflix.com",
"status": 200,
"scan_depth": "full",
"technologies": [
{
"name": "React",
"categories": ["JavaScript frameworks"],
"confidence": 100,
"version": "18.2",
"website": "https://reactjs.org",
"cpe": "cpe:2.3:a:facebook:react:18.2:*:*:*:*:*:*:*"
},
{
"name": "Next.js",
"categories": ["JavaScript frameworks"],
"confidence": 100,
"website": "https://nextjs.org"
}
]
}

Key fields to look at:

name — The technology name. React and Next.js are reported separately, so you can distinguish between the two.
confidence — How certain the detection is (0-100). A confidence of 100 means the fingerprint matched unambiguously.
version — When detectable, the specific React version. Useful for security auditing—you can cross-reference this against known CVEs.
cpe — The CPE identifier for the technology, letting you look up vulnerabilities in the NVD directly.
categories — React appears under “JavaScript frameworks.” This lets you filter the response to only show front-end frameworks.

Batch Detection Across Multiple Sites

To scan a list of domains for React usage, loop through them with curl or use a script. Here is a quick bash one-liner:

$ for domain in netflix.com airbnb.com stripe.com; do
echo -n "$domain: "
curl -s "https://detectzestack.p.rapidapi.com/analyze?url=$domain" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
| jq -r '[.technologies[] | select(.name == "React" or .name == "Next.js") | .name] | if length == 0 then "not detected" else join(", ") end'
done

For larger-scale scanning, see the Python tutorial which covers batch scanning with rate limiting and CSV export.

React vs Next.js — What the Detection Tells You

Every Next.js site uses React, but not every React site uses Next.js. Understanding the distinction matters for competitive analysis and technical assessment:

Signal	Plain React (CRA/Vite)	Next.js
Root element
Page data	None in source	NEXT_DATA script tag
Asset paths	/static/js/main.*.js	/_next/static/chunks/*.js
HTTP headers	None specific	X-Nextjs-Cache (on ISR pages)
SSR	Possible but manual	Built-in (SSR/SSG/ISR)
Rendering pattern	Client-side (empty shell)	Server-rendered HTML

When the DetectZeStack API reports both “React” and “Next.js,” it means the site uses Next.js as the framework layer on top of React. If only “React” is reported, the site uses React directly—possibly with Create React App, Vite, Gatsby, Remix, or a custom setup.

Other React-based frameworks you may see detected alongside React include Gatsby (which uses React for its component model and adds a static site generation layer) and Remix (which, like Next.js, adds server-side rendering to React). For a broader overview of detecting all JavaScript frameworks, see How to Detect What JavaScript Framework a Website Uses.

Why this matters for sales: A company running Next.js has likely invested in performance and SEO—they may be interested in monitoring and analytics tools. A company running a client-side React SPA may be more interested in performance optimization and bundle analysis tools. The framework choice signals the team’s priorities. For more on using tech detection for outreach, see Tech Stack Enrichment for Sales Teams.

Get Started with Programmatic React Detection

Manual checks are fine for occasional curiosity. For anything systematic—lead qualification, competitive research, security scanning, or portfolio analysis—an API is the only practical approach.

The DetectZeStack API gives you React detection plus 7,300+ other technology fingerprints in a single call. Every request also includes DNS-based infrastructure detection, TLS certificate analysis, and CPE identifiers for vulnerability lookups—layers that no browser-based method can match.

The free tier includes 100 requests per month with no credit card required. That is enough to scan your competitor list, audit a client portfolio, or build a proof-of-concept integration.

How to Detect if a Website Uses Intercom: 5 Methods

MikeL — Wed, 15 Apr 2026 20:42:00 +0000

Intercom is one of the most popular customer messaging platforms on the web. Companies use it for live chat, in-app messaging, help centers, and product tours—making it a key indicator of how a business handles customer communication. From the outside, the familiar chat bubble in the bottom-right corner is a strong hint, but it is not always visible: some sites customize or delay-load the widget, and others use Intercom only for backend messaging without a visible launcher.

Whether you are qualifying sales leads, analyzing a competitor’s support stack, auditing third-party scripts for security, or planning a migration off Intercom, reliably detecting it matters. This guide covers five methods: from quick manual checks to a fully programmatic API approach that works at scale.

Why Detect Intercom on a Website

Intercom is more than a chat widget. Detecting it on a website tells you several things about the business behind it.

Budget signal. Intercom pricing starts around $39/month for very small teams and scales to $139/month or more for growth-stage companies. Businesses running Intercom have allocated budget for customer communication tooling—they are not using a free contact form.

Customer engagement maturity. Intercom implies a proactive approach to customer support and engagement. Sites running Intercom typically have a support team, defined response SLAs, and automated workflows. This is useful context for sales prospecting: these are companies that invest in customer experience.

Third-party script inventory. For security teams, knowing that Intercom’s JavaScript is loaded on a site matters. The Intercom messenger injects iframes, loads external scripts from intercomcdn.com, and sets persistent cookies. Any third-party script with that level of page access is worth tracking in a vendor audit.

Migration planning. If you are evaluating a move from Intercom to Zendesk, Drift, Crisp, or another platform, the first step is understanding exactly which Intercom features are in use: just the messenger widget, or also articles, product tours, and automated messages. The detection methods below help you inventory the integration depth.

Method 1 — Check the Page Source for Intercom Scripts

The simplest way to detect Intercom is to view the page source and search for its script signatures. In any browser, press Ctrl+U (or Cmd+Option+U on macOS) to view source, then search for these strings:

widget.intercom.io — the Intercom messenger widget stylesheet
intercomcdn.com — Intercom’s CDN for JavaScript assets
api.intercom.io — the Intercom API endpoint for messenger initialization
intercom in inline script blocks — the window.intercomSettings configuration object

What to Look For in the HTML

The standard Intercom installation embeds a JavaScript snippet that configures and boots the messenger. It typically looks like this:

<script>
window.intercomSettings = {
api_base: "https://api-iam.intercom.io",
app_id: "abc123de"
};
</script>
<script>
(function(){var w=window;var ic=w.Intercom;if(typeof ic==="function"){
ic('reattach_activator');ic('update',w.intercomSettings);}else{
var d=document;var i=function(){i.c(arguments);};i.q=[];i.c=function(args){
i.q.push(args);};w.Intercom=i;var l=function(){var s=d.createElement('script');
s.type='text/javascript';s.async=true;
s.src='https://widget.intercom.io/widget/abc123de';
var x=d.getElementsByTagName('script')[0];
x.parentNode.insertBefore(s,x);};l();}})();
</script>

The app_id value (abc123de in this example) identifies the Intercom workspace. Every Intercom account has a unique app ID, which appears in both the intercomSettings object and the widget script URL.

Script Pattern	Component	What It Means
widget.intercom.io/widget/{app_id}	Messenger widget	Live chat and in-app messaging active
static.intercomcdn.com	CDN assets	Intercom JavaScript bundle loaded
api.intercom.io	API endpoint	Messenger communicating with Intercom backend
window.intercomSettings	Config object	Intercom initialized with workspace settings

Limitation: Viewing page source only shows scripts in the initial HTML. If Intercom is loaded after cookie consent or on specific pages only (e.g., the app dashboard but not the marketing site), it will not appear in the source of every page. Method 3 catches these cases by checking what the browser actually rendered.

Method 2 — Inspect Cookies and Local Storage

Intercom sets distinctive cookies and local storage entries that persist even if the messenger widget is not visible on the current page. Open Chrome DevTools (F12), go to Application > Cookies, and look for these patterns:

Intercom Cookies

Cookie Name Pattern	Purpose	Lifetime
intercom-session-{app_id}	Session tracking for the messenger	1 week
intercom-id-{app_id}	Anonymous visitor identity	9 months
intercom-device-id-{app_id}	Device fingerprint for cross-session tracking	9 months

The {app_id} in the cookie name matches the workspace ID from the script installation. If you see any cookie starting with intercom-, that site runs Intercom.

Local Storage Entries

Intercom also writes to localStorage. In DevTools, go to Application > Local Storage and look for keys starting with intercom.:

intercom.intercom-state-{app_id} — messenger state (open/closed, unread count)
intercom.intercom-id — visitor identity token

Local storage entries persist across browser sessions and are a reliable indicator even when the Intercom widget has not fully loaded on the current page.

Note: Cookies and local storage are set by client-side JavaScript, not by the server. A simple curl request will not trigger them. For cookie-based detection, you need to visit the site in a browser or headless browser that executes JavaScript.

Method 3 — Look for the Intercom Messenger Widget in the DOM

Once Intercom loads, it injects specific DOM elements into the page. These are reliable fingerprints because they use fixed IDs and attribute patterns that Intercom has maintained across versions.

Open Chrome DevTools (F12), go to the Console tab, and run these checks:

// Check for the Intercom messenger iframe
document.querySelector('iframe#intercom-frame')
// Returns the iframe element if Intercom is loaded, null otherwise

// Check for the Intercom widget stylesheet
document.querySelector('link[href*="widget.intercom.io"]')
// Returns the link element if present

// Check for the Intercom launcher (the chat bubble)
document.querySelector('.intercom-launcher')
// Returns the launcher button element

If any of these return an element (not null), Intercom is active on the page.

DOM Selector	Element	What It Confirms
iframe#intercom-frame	Messenger iframe	Intercom messenger widget is loaded and rendered
link[href*="widget.intercom.io"]	Widget stylesheet	Intercom CSS has been injected into the page
.intercom-launcher	Chat bubble	The visible launcher button is present
#intercom-container	Widget container	The messenger container div exists in the DOM

DOM inspection catches Intercom even when it is loaded dynamically after page load, behind a cookie consent banner, or via a tag manager like Google Tag Manager. It is more reliable than source inspection for single-page applications where the initial HTML is minimal.

Method 4 — Check the JavaScript Global Object

Intercom exposes a global window.Intercom function that serves as its public API. This is one of the most reliable detection methods because Intercom requires this global to function—it cannot operate without it.

In the browser console:

// Check if the Intercom global exists
typeof window.Intercom
// Returns "function" if Intercom is loaded, "undefined" otherwise

// Get the Intercom app ID from the booted instance
window.Intercom.booted
// Returns true if the messenger has been initialized

The window.Intercom function is used by the site’s own code to control the messenger: showing/hiding it, passing user data, triggering messages. Because it is part of Intercom’s public API contract, it is stable across versions and not likely to change.

You can also extract configuration details:

// If intercomSettings is available, read the app ID
window.intercomSettings && window.intercomSettings.app_id
// Returns the workspace app ID (e.g., "abc123de")

Tip: Methods 3 and 4 (DOM and JavaScript global) require visiting the page in a browser. For automated detection across many domains, Method 5 (the API approach) handles this by performing full HTTP analysis server-side, including JavaScript fingerprinting.

Method 5 — Use the DetectZeStack API for Programmatic Detection

When you need to detect Intercom across hundreds or thousands of domains—for lead qualification, market research, or vendor auditing—manual methods do not scale. The DetectZeStack API detects Intercom via HTTP fingerprinting in a single request, alongside 7,300+ other technologies.

Single URL Analysis with curl

Try it without signing up. The /demo endpoint is rate-limited to 20 requests per hour per IP, but requires no authentication:

$ curl -s "https://detectzestack.com/demo?url=intercom.com" | jq '.'
{
"url": "https://intercom.com",
"domain": "intercom.com",
"technologies": [
{
"name": "Intercom",
"categories": ["Live chat", "Customer engagement"],
"confidence": 100,
"source": "http"
},
{
"name": "React",
"categories": ["JavaScript frameworks"],
"confidence": 100,
"source": "http"
},
...
],
"categories": {
"Live chat": ["Intercom"],
"Customer engagement": ["Intercom"],
"JavaScript frameworks": ["React"],
...
},
"meta": {
"status_code": 200,
"tech_count": 18,
"scan_depth": "full"
},
"cached": false,
"response_ms": 920
}

Notice the source: "http" field on Intercom—the API detected it through HTTP fingerprinting, matching script patterns like widget.intercom.io and DOM elements like iframe#intercom-frame. This is the automated equivalent of Methods 1 through 4 combined.

Batch Detection Across Multiple Sites

For production use, the /analyze endpoint supports higher rate limits and is available through RapidAPI. To scan multiple domains, use the /analyze/batch endpoint:

$ 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": ["intercom.com", "drift.com", "zendesk.com"]}' | jq '.'

The batch endpoint accepts up to 10 URLs per request and returns results for each domain. This is ideal for building a spreadsheet of which prospects use Intercom versus competing live chat platforms like Drift, Zendesk, Crisp, or LiveChat.

Reading the API Response

The response structure makes it straightforward to filter for Intercom and related customer engagement technologies:

# Check if Intercom is present on a site
$ curl -s "https://detectzestack.com/demo?url=example.com" | \
jq '.technologies[] | select(.name == "Intercom")'

# Find all live chat tools on a site
$ curl -s "https://detectzestack.com/demo?url=example.com" | \
jq '.categories["Live chat"]'

The categories object groups technologies by function. Intercom appears under “Live chat” and “Customer engagement”. You can use this to find all customer communication tools on a site at once—Intercom alongside tools like Zendesk, Drift, Freshdesk, or HubSpot.

Common Use Cases for Intercom Detection

Competitive Intelligence for Sales Teams

If you sell customer support software, CRM tools, or competing messaging platforms, knowing which companies use Intercom is directly actionable. Intercom customers have already committed to a customer messaging strategy and have budget allocated for it. They are qualified prospects for any product that integrates with or replaces Intercom.

Combine Intercom detection with other tech stack signals to build richer prospect profiles. A company running Intercom alongside HubSpot likely has a mature marketing and support stack. A company using Intercom with Stripe has an online payment flow and is likely a SaaS or e-commerce business. These combinations tell you more than any single technology detection. For a deeper look at using technographic data in sales, see Sales Teams: Competitive Intelligence with Tech Stack Data.

Security Auditing Third-Party Scripts

Intercom’s messenger loads external JavaScript, injects iframes, sets persistent cookies, and writes to local storage. For security-conscious organizations, tracking which third-party scripts have this level of access is essential for vendor auditing and compliance.

Use the DetectZeStack API to inventory all third-party scripts on your domains. Intercom is one of many live chat and analytics tools that inject client-side code—knowing exactly which ones are present helps you assess your attack surface and maintain an accurate vendor register.

Migration Planning

If you are considering a switch from Intercom to another platform (or the reverse), the detection methods above tell you exactly which Intercom components are in use. A site that only loads the messenger widget is a simpler migration than one using Intercom Articles (help center), Product Tours, and automated messaging workflows.

The API response categorizes Intercom under “Live chat” and “Customer engagement.” If the API also detects “Intercom Articles” (a separate technology entry), you know the help center is in use too—that is a larger migration scope.

Intercom Detection at Scale

Here is a practical Python script to scan a list of domains and flag which ones use Intercom:

import requests
import csv
import time

API_URL = "https://detectzestack.p.rapidapi.com/analyze"
HEADERS = {
"X-RapidAPI-Key": "YOUR_KEY",
"X-RapidAPI-Host": "detectzestack.p.rapidapi.com"
}

domains = ["intercom.com", "drift.com", "zendesk.com", "crisp.chat"]

with open("intercom_audit.csv", "w", newline="") as f:
writer = csv.writer(f)
writer.writerow(["domain", "has_intercom", "categories", "other_live_chat"])

for domain in domains:
resp = requests.get(API_URL, headers=HEADERS, params={"url": domain})
data = resp.json()

intercom = [
t for t in data.get("technologies", [])
if t["name"] == "Intercom"
]

live_chat = data.get("categories", {}).get("Live chat", [])
other_chat = [t for t in live_chat if t != "Intercom"]

if intercom:
tech = intercom[0]
writer.writerow([
domain, True,
", ".join(tech.get("categories", [])),
", ".join(other_chat) if other_chat else ""
])
print(f"{domain}: Intercom detected")
else:
writer.writerow([domain, False, "", ", ".join(live_chat)])
print(f"{domain}: no Intercom")

time.sleep(0.5)  # respect rate limits

This produces a CSV with each domain, whether Intercom was found, its categories, and any competing live chat tools detected on the same site. For a more complete tutorial covering batch endpoints and error handling, see Detect Any Website’s Tech Stack with Python.

Conclusion and Next Steps

Detecting Intercom manually works for one-off checks: view the source for widget.intercom.io, check cookies for intercom-session- prefixes, look for iframe#intercom-frame in the DOM, or test window.Intercom in the console. Each method catches a different aspect of the integration.

For anything beyond a handful of sites—building prospect lists, monitoring competitor stacks, or auditing vendor dependencies—the DetectZeStack API automates all detection methods in a single request. One call returns Intercom, HubSpot, Google Analytics, and every other technology on the site, with structured JSON output that feeds directly into your pipeline.

I Built an API That Detects 7,200+ Technologies — Here's How It Works

MikeL — Tue, 10 Mar 2026 02:49:22 +0000

You visit a website. Within seconds, you want to know: what's it built with? What CDN? What framework? What analytics?

I needed this for a project — bulk tech stack detection across thousands of domains. Wappalyzer's browser extension is great for one-off lookups, but I needed an API that could handle volume, return structured data, and catch things the browser extension misses.

So I built DetectZeStack, a tech stack detection API in Go. It scans 7,200+ technologies using four detection layers. Here's how it works under the hood.

The Problem With Single-Layer Detection

Most tech detection tools rely on one method: matching patterns in HTML, headers, and JavaScript. That's what Wappalyzer does, and it's genuinely good at it.

But it misses things:

DNS-level infrastructure (CDNs, hosting providers identified by CNAME records)
TLS certificate issuers (tells you who provides their SSL — Cloudflare, AWS, Let's Encrypt)
Infrastructure headers that aren't in the fingerprint database

A site behind Cloudflare with a React frontend might only show "React" with single-layer detection. You'd miss the CDN, the certificate authority, and the hosting provider.

The Four Detection Layers

Layer 1: Wappalyzer Fingerprinting (7,200+ signatures)

The foundation. I use wappalyzergo, which ports Wappalyzer's fingerprint database to Go. It analyzes:

HTML content (meta tags, script sources, DOM patterns)
HTTP response headers (Server, X-Powered-By, etc.)
JavaScript variables and objects
Cookie names and patterns

This alone catches most frontend frameworks, CMS platforms, analytics tools, and e-commerce platforms.

Layer 2: DNS CNAME/NS Fingerprinting (111 signatures)

Here's where it gets interesting. When you resolve a domain's DNS, the CNAME chain reveals infrastructure:

stripe.com → stripe.com.cdn.cloudflare.net → ...

That CNAME tells you Cloudflare is involved, even if the HTTP headers are scrubbed clean.

I maintain 111 DNS signatures mapping CNAME patterns to technologies:

*.cloudfront.net → Amazon CloudFront
*.fastly.net → Fastly
*.netlify.app → Netlify
*.vercel-dns.com → Vercel
*.herokuapp.com → Heroku

The DNS lookup runs in parallel with the HTTP fetch, so it adds zero latency. If DNS times out (2-second cap), the scan still returns HTTP-based results.

Layer 3: TLS Certificate Analysis

Every HTTPS connection includes a TLS handshake with the server's certificate. The certificate issuer reveals the SSL/TLS provider:

Certificate Issuer	Technology
Cloudflare, Inc.	Cloudflare SSL
Amazon	AWS Certificate Manager
Let's Encrypt	Let's Encrypt
Google Trust Services	Google Cloud
DigiCert Inc	DigiCert

This is essentially free — the cert info is already in the TLS handshake, no extra request needed.

Layer 4: Custom Header Matching

Some infrastructure providers add unique headers that aren't in Wappalyzer's database:

X-Railway-Request-Id → Railway (PaaS)
X-Amz-Cf-Pop → Amazon CloudFront (edge location)
X-Nf-Request-Id → Netlify

These fill gaps where standard fingerprinting falls short.

Deduplication

When multiple layers detect the same technology, the API deduplicates by name. If Wappalyzer detects "Cloudflare" from headers AND DNS detects "Cloudflare" from CNAME, you get one entry — not two.

Higher-confidence detections take priority. Wappalyzer's pattern match at 100% confidence beats a DNS-only detection at 80%.

What the Output Looks Like

Here's a real scan of stripe.com:

curl "https://detectzestack.com/demo?url=stripe.com"

{
  "url": "https://stripe.com",
  "domain": "stripe.com",
  "technologies": [
    {
      "name": "Amazon S3",
      "categories": ["CDN"],
      "confidence": 100,
      "description": "Amazon S3 or Amazon Simple Storage Service...",
      "website": "https://aws.amazon.com/s3/",
      "icon": "Amazon S3.svg"
    },
    {
      "name": "Amazon Web Services",
      "categories": ["PaaS"],
      "confidence": 100,
      "website": "https://aws.amazon.com/"
    },
    {
      "name": "DigiCert",
      "categories": ["SSL/TLS certificate authority"],
      "confidence": 70
    },
    {
      "name": "HSTS",
      "categories": ["Security"],
      "confidence": 100
    },
    {
      "name": "Nginx",
      "categories": ["Web servers", "Reverse proxies"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*"
    }
  ],
  "categories": {
    "CDN": ["Amazon S3"],
    "PaaS": ["Amazon Web Services"],
    "Security": ["HSTS"],
    "SSL/TLS certificate authority": ["DigiCert"],
    "Web servers": ["Nginx"]
  },
  "meta": {
    "status_code": 200,
    "tech_count": 5,
    "scan_depth": "full"
  }
}

Notice the DigiCert entry with 70% confidence — that came from TLS certificate analysis (Layer 3), not HTML fingerprinting.

And here's github.com, which returns 8 technologies:

curl "https://detectzestack.com/demo?url=github.com"

{
  "technologies": [
    { "name": "Amazon S3", "categories": ["CDN"], "confidence": 100 },
    { "name": "Amazon Web Services", "categories": ["PaaS"], "confidence": 100 },
    { "name": "C3.js", "categories": ["JavaScript libraries"], "confidence": 100 },
    { "name": "Contentful", "categories": ["CMS"], "confidence": 100 },
    { "name": "GitHub Pages", "categories": ["PaaS"], "confidence": 100 },
    { "name": "HSTS", "categories": ["Security"], "confidence": 100 },
    { "name": "React", "categories": ["JavaScript frameworks"], "confidence": 100 },
    { "name": "Sectigo", "categories": ["SSL/TLS certificate authority"], "confidence": 70 }
  ]
}

Contentful (CMS), C3.js (charting), React (frontend), Sectigo (TLS) — all from a single API call.

Architecture Decisions

Why Go? Concurrency is first-class. The DNS lookup, HTTP fetch, and TLS extraction all run in parallel goroutines. A typical scan completes in 1-2 seconds.

Why not just wrap the Wappalyzer npm package? Performance and deployability. The Go binary is a single executable, ~15MB, runs on a $3/month Fly.io instance. No Node.js runtime, no headless browser, no Puppeteer.

Why SQLite for storage? The API caches scan results to avoid hammering target sites. SQLite is perfect for this — single-file database, zero configuration, handles thousands of concurrent reads. It runs alongside the API process on the same machine.

Why not headless browser rendering? Some JavaScript-heavy sites would benefit from it, but it would 10x the infrastructure cost and response time. Wappalyzer's static analysis catches the vast majority of technologies. If you need rendered-page analysis, tools like Wappalyzer's browser extension are the right choice.

Try It

The /demo endpoint is free, no signup needed:

# Try it right now
curl "https://detectzestack.com/demo?url=your-site.com"

For production use (higher rate limits, change tracking, history), it's on RapidAPI with a free tier — 100 requests/month, no credit card.

There are also alternatives worth considering: Wappalyzer's npm package if you want to self-host detection, and BuiltWith if you need historical data going back years. DetectZeStack's differentiator is the multi-layer detection approach and the structured API response with confidence scores.

If you're building anything that needs tech stack data — competitive analysis, security auditing, lead enrichment — I'd love to hear about your use case. Drop a comment or find me on Twitter/X.

Build a Website Tech Stack Scanner in Python (Under 50 Lines)

MikeL — Sun, 08 Mar 2026 01:31:49 +0000

Ever wonder what tech stack a website is running? Maybe you're scoping out a competitor, enriching leads, or checking for outdated frameworks with known vulnerabilities.

Here's a Python script that does it in under 50 lines. It calls a tech detection API, parses the response, and gives you a clean report.

The Full Script

import requests
import sys

API_URL = "https://detectzestack.p.rapidapi.com/analyze"
HEADERS = {
    "X-RapidAPI-Key": "YOUR_API_KEY",
    "X-RapidAPI-Host": "detectzestack.p.rapidapi.com"
}

def scan(url):
    resp = requests.get(API_URL, headers=HEADERS, params={"url": url})
    resp.raise_for_status()
    return resp.json()

def report(data):
    print(f"\n{'=' * 50}")
    print(f"  {data['domain']}  (HTTP {data['status_code']})")
    print(f"  Scanned in {data['detection_time_ms']}ms")
    print(f"{'=' * 50}")

    # Group by category
    by_cat = {}
    for tech in data["technologies"]:
        cat = tech["category"]
        by_cat.setdefault(cat, []).append(tech)

    for cat, techs in sorted(by_cat.items()):
        print(f"\n  {cat}:")
        for t in techs:
            ver = f" v{t['version']}" if t.get("version") else ""
            src = f"[{t['source']}]"
            cpe = f"\n      CPE: {t['cpe']}" if t.get("cpe") else ""
            print(f"    - {t['name']}{ver} {src}{cpe}")

    print(f"\n  Total: {len(data['technologies'])} technologies detected")

if __name__ == "__main__":
    urls = sys.argv[1:] or ["stripe.com"]
    for url in urls:
        report(scan(url))

Save this as scan.py and run it:

python scan.py stripe.com github.com shopify.com

Sample Output

Here's what you get for stripe.com:

==================================================
  stripe.com  (HTTP 200)
  Scanned in 847ms
==================================================

  CDN:
    - Cloudflare [dns]

  JavaScript frameworks:
    - React [wappalyzer]

  Web servers:
    - Nginx v1.25.3 [wappalyzer]
      CPE: cpe:2.3:a:f5:nginx:1.25.3:*:*:*:*:*:*:*

  Analytics:
    - Google Analytics [wappalyzer]

  SSL/TLS certificate authorities:
    - Let's Encrypt [tls]

  Total: 5 technologies detected

What's Happening Under the Hood

The API uses four detection layers:

1. HTTP Header Fingerprinting
Headers like Server: nginx/1.25.3 and X-Powered-By: Express reveal the web server and framework. Fast, but many production sites strip these.

2. HTML/DOM Pattern Matching
The API scans page source for known patterns: <meta name="generator" content="WordPress">, script URLs containing react.production.min.js, CSS class patterns like Tailwind's utilities. This is the core engine — over 7,200 technology signatures via wappalyzergo.

3. DNS CNAME Analysis
A DNS lookup reveals infrastructure that HTTP can't see. example.com CNAME d1234.cloudfront.net → Amazon CloudFront. The API checks against 111 CDN/hosting provider signatures.

4. TLS Certificate Inspection
The certificate authority correlates with infrastructure: Let's Encrypt → self-hosted, Cloudflare Inc → Cloudflare proxy, Amazon → AWS.

Each technology in the response includes a source field (wappalyzer, dns, tls, or headers) so you know exactly how it was detected.

Extending It: Batch Analysis

Need to scan multiple URLs efficiently? The API has a batch endpoint:

import requests

urls = ["stripe.com", "shopify.com", "github.com",
        "notion.so", "vercel.com"]

resp = requests.post(
    "https://detectzestack.p.rapidapi.com/batch",
    headers={
        "X-RapidAPI-Key": "YOUR_API_KEY",
        "X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
        "Content-Type": "application/json"
    },
    json={"urls": urls}
)

for result in resp.json()["results"]:
    techs = [t["name"] for t in result["technologies"]]
    print(f"{result['domain']}: {', '.join(techs)}")

This sends one HTTP request instead of five.

Extending It: Security Scanning with CPE

The cpe field in the response maps detected technologies to the NVD (National Vulnerability Database). You can cross-reference it to check for known CVEs:

for tech in data["technologies"]:
    if tech.get("cpe"):
        print(f"  {tech['name']} → {tech['cpe']}")
        # Query NVD: https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName={cpe}

This is useful for security audits and compliance checks.

Getting an API Key

The API is on RapidAPI. The free tier gives you 100 requests/month — no credit card required. Enough to build and test with.

Paid plans start at $9/month for 1,000 requests if you need more volume.

What are you building with tech detection? Competitive analysis dashboards? Lead enrichment pipelines? Security scanners? Drop a comment — I'd love to hear your use case.

DEV Community: MikeL

How to Detect cdnjs on Any Website (API Guide)

What Is cdnjs and Why Detect It

How cdnjs Shows Up in a Website's Source

Script tags pointing to cdnjs.cloudflare.com

Library and version fingerprints cdnjs leaves behind

Manual Ways to Detect cdnjs (and Their Limits)

Detect cdnjs Programmatically with the DetectZeStack API

Reading the technologies, version, and categories fields

Detecting cdnjs Across Many Sites at Scale

cdnjs vs Other JavaScript CDNs

Get Your API Key and Start Detecting cdnjs

Conclusion

Related Reading

Find Companies Using jsDelivr: Technographic API Guide

Why Find Companies Using jsDelivr?

What jsDelivr Tells You About a Tech Stack

jsDelivr vs Self-Hosted Libraries and Other CDNs

How DetectZeStack Detects jsDelivr

API Example: Detecting jsDelivr With a Single Call

Building a List of Companies Using jsDelivr at Scale

Use Cases: Sales, Competitive Intelligence, and Security

Get Started With the DetectZeStack API

Conclusion

Related Reading

How to Find Companies Using MySQL: API Guide for 2026

Why Build a List of Companies Using MySQL

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

How MySQL Detection Works (and Its Limits)

Indirect Signals: CMS and Ecommerce Platform Implications

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

Find MySQL-Backed Sites with the DetectZeStack API

Single Domain Check with /analyze

Scaling Up with POST /analyze/batch

Building a Prospect List: From Detection to Outreach

Comparing Two Prospects with POST /compare

MySQL Detection vs Other Technographic Tools

Conclusion and Next Steps

Related Reading

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

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

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

Email Security Records: SPF, DMARC, DKIM

How DetectZeStack Grades Email Security

DNS Lookup API vs Running dig Yourself

Using the DetectZeStack /dns Endpoint (curl example)

Sample JSON Response

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

1. Pre-migration audit

2. Deliverability triage

3. Lead enrichment

4. Infrastructure-change monitoring

Pricing and Rate Limits

Getting Started in 60 Seconds

Related Reading

StackShare Alternative: Programmatic Tech Stack Research API

Why Look for a StackShare Alternative

What StackShare Offers (and What’s Missing)

The API Gap

DetectZeStack as a Programmatic StackShare Alternative

Live Detection vs Crowdsourced Profiles

DNS, SSL, and Security Signals StackShare Doesn’t Cover

API Example: Pulling a Company’s Tech Stack in One Call

Comparing Two Companies’ Stacks Programmatically

Use Cases: Sales Research, Competitive Intel, and Lead Enrichment

Pricing and Getting Started

Conclusion

Related Reading

Set Up Webhook Tech Stack Changes Alerts via API

Why Monitor Websites for Tech Stack Changes

Use Cases for Webhook Tech Stack Changes Alerts

How DetectZeStack Webhook Alerts Work

The Webhook Lifecycle

Step 1 — Create a Webhook Subscription

Webhook Limits by Plan

Step 2 — Enable Scheduled Monitoring

Daily vs Weekly Monitoring Intervals

Step 3 — Receive and Verify Webhook Payloads

HMAC Signature Verification

Payload Structure

DNS Lookup API vs Running `dig` Yourself