DEV Community: MikeL

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

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

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

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

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

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

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

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

Manual Ways to Detect Typekit on a Website

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

Check for use.typekit.net Script and Stylesheet URLs

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

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

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

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

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

Look for the Kit ID and wf-loading Body Classes

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

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

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

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

Inspect Network Requests to p.typekit.net

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

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

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

Why Manual Detection Breaks at Scale

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

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

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

Detect Typekit With the DetectZeStack API

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

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

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

Which returns:

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

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

Single Domain Check With /analyze

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

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

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

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

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

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

Scanning Many Domains With POST /analyze/batch

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

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

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

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

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

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

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

Get Your API Key and Start Detecting

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

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

Conclusion

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

Find Companies Using imagesLoaded: API Guide (2026)

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

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

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

What Is imagesLoaded and Why Track Sites That Use It

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

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

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

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

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

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

Who Buys From Companies Using imagesLoaded

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

Agencies and Freelancers Selling Front-End Modernization

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

SaaS Vendors Replacing Custom Gallery and Layout Code

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

How DetectZeStack Detects imagesLoaded

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

Script Signatures and CDN Fingerprints

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

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

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

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

API Example: Check a Single Domain for imagesLoaded

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

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

Which returns:

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

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

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

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

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

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

API Example: Build a List of Companies Using imagesLoaded

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

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

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

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

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

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

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

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

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

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

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

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

Turning Detections Into a Prospect List

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

import csv
import requests

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

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

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

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

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

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

if __name__ == "__main__":
main()

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

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

Get Started

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

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

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

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

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

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

Why Find Companies Using WP Engine?

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

Sales Prospecting for WordPress Agencies and Plugin Vendors

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

Competitive and Migration Intelligence

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

How WP Engine Reveals Itself (Detection Signals)

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

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

DNS CNAME Records Pointing to *.wpengine.com

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

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

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

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

WP Engine Cache Headers and Server Fingerprints

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

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

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

Why Header Checks Alone Miss Hardened Sites

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

Manual Detection Methods (and Their Limits)

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

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

Detect WP Engine with the DetectZeStack API

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

Single Domain Check with /analyze (curl example)

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

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

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

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

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

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

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

Scanning a Lead List with /analyze/batch

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

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

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

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

Building a WP Engine Prospect List Workflow

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

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

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

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
curl -s -X POST "https://$HOST/analyze/batch" \
-H "X-RapidAPI-Key: $KEY" \
-H "X-RapidAPI-Host: $HOST" \
-H "Content-Type: application/json" \
-d "$urls" |
jq -r '.results[]
| select(.result != null)
| .result as $r
| ($r.technologies[] | select(.name == "WP Engine")) as $wpe
| [$r.domain, $wpe.source, ($r.meta.tech_count | tostring)]
| @csv' >> wpengine_leads.csv
done

wc -l wpengine_leads.csv

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

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

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

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

Get Started with a Free API Key

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

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

Conclusion

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

How to Detect cdnjs on Any Website (API Guide)

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

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

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

What Is cdnjs and Why Detect It

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

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

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

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

How cdnjs Shows Up in a Website's Source

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

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

Script tags pointing to cdnjs.cloudflare.com

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

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

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

Library and version fingerprints cdnjs leaves behind

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

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

Manual Ways to Detect cdnjs (and Their Limits)

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

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

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

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

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

Detect cdnjs Programmatically with the DetectZeStack API

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

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

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

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

Reading the technologies, version, and categories fields

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

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

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

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

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

Detecting cdnjs Across Many Sites at Scale

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

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

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

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

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

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

echo "domain,tech_count" > cdnjs_leads.csv

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
curl -s -X POST "https://$HOST/analyze/batch" \
-H "X-RapidAPI-Key: $KEY" \
-H "X-RapidAPI-Host: $HOST" \
-H "Content-Type: application/json" \
-d "$urls" |
jq -r '.results[]
| select(.result != null)
| .result as $r
| select([$r.technologies[].name] | index("cdnjs"))
| [$r.domain, ($r.meta.tech_count | tostring)]
| @csv' >> cdnjs_leads.csv
done

wc -l cdnjs_leads.csv

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

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

cdnjs vs Other JavaScript CDNs

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

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

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

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

Get Your API Key and Start Detecting cdnjs

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

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

Conclusion

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

Find Companies Using jsDelivr: Technographic API Guide

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

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

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

Why Find Companies Using jsDelivr?

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

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

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

What jsDelivr Tells You About a Tech Stack

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

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

jsDelivr vs Self-Hosted Libraries and Other CDNs

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

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

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

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

How DetectZeStack Detects jsDelivr

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

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

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

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

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

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

API Example: Detecting jsDelivr With a Single Call

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

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

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

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

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

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

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

Building a List of Companies Using jsDelivr at Scale

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

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

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

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

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

echo "domain,tech_count" > jsdelivr_leads.csv

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
curl -s -X POST "https://$HOST/analyze/batch" \
-H "X-RapidAPI-Key: $KEY" \
-H "X-RapidAPI-Host: $HOST" \
-H "Content-Type: application/json" \
-d "$urls" |
jq -r '.results[]
| select(.result != null)
| .result as $r
| select([$r.technologies[].name] | index("jsDelivr"))
| [$r.domain, ($r.meta.tech_count | tostring)]
| @csv' >> jsdelivr_leads.csv
done

wc -l jsdelivr_leads.csv

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

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

Use Cases: Sales, Competitive Intelligence, and Security

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

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

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

Get Started With the DetectZeStack API

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

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

Conclusion

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

How to Find Companies Using MySQL: API Guide for 2026

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

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

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

Why Build a List of Companies Using MySQL

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

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

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

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

How MySQL Detection Works (and Its Limits)

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

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

Indirect Signals: CMS and Ecommerce Platform Implications

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

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

Two honest caveats before you build a pipeline on this:

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

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

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

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

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

Find MySQL-Backed Sites with the DetectZeStack API

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

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

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

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

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

Single Domain Check with /analyze

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

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

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

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

Scaling Up with POST /analyze/batch

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

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

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

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
curl -s -X POST "https://$HOST/analyze/batch" \
-H "X-RapidAPI-Key: $KEY" \
-H "X-RapidAPI-Host: $HOST" \
-H "Content-Type: application/json" \
-d "$urls" |
jq -r '.results[]
| select(.result != null)
| select(.result.categories["Databases"] // [] | contains(["MySQL"]))
| [.result.domain,
((.result.categories["CMS"] // .result.categories["Ecommerce"] // ["unknown"])[0]),
(.result.meta.tech_count | tostring)]
| @csv' >> mysql_leads.csv
done

wc -l mysql_leads.csv

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

Building a Prospect List: From Detection to Outreach

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

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

Comparing Two Prospects with POST /compare

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

$ curl -s -X POST "https://detectzestack.p.rapidapi.com/compare" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
-H "Content-Type: application/json" \
-d '{"urls": ["prospect-a.com", "prospect-b.com"]}' \
| jq '{shared, unique_a: .domains[0].unique, unique_b: .domains[1].unique}'
{
"shared": ["WordPress", "MySQL", "PHP", "Nginx"],
"unique_a": ["WooCommerce", "Cloudflare"],
"unique_b": ["HubSpot"]
}

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

MySQL Detection vs Other Technographic Tools

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

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

Conclusion and Next Steps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Email Security Records: SPF, DMARC, DKIM

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

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

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

How DetectZeStack Grades Email Security

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

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

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

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

DNS Lookup API vs Running `dig` Yourself

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

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

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

Using the DetectZeStack /dns Endpoint (curl example)

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

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

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

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

That call returns the technology-detection response shape:

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

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

Sample JSON Response

A realistic /dns response looks like this:

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

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

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

1. Pre-migration audit

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

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

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

2. Deliverability triage

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

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

3. Lead enrichment

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

4. Infrastructure-change monitoring

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

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

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

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

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

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

Pricing and Rate Limits

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

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

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

Getting Started in 60 Seconds

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

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.

DEV Community: MikeL

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

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

Manual Ways to Detect Typekit on a Website

Check for use.typekit.net Script and Stylesheet URLs

Look for the Kit ID and wf-loading Body Classes

Inspect Network Requests to p.typekit.net

Why Manual Detection Breaks at Scale

Detect Typekit With the DetectZeStack API

Single Domain Check With /analyze

Scanning Many Domains With POST /analyze/batch

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

Get Your API Key and Start Detecting

Conclusion

Related Reading

Find Companies Using imagesLoaded: API Guide (2026)

What Is imagesLoaded and Why Track Sites That Use It

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

Who Buys From Companies Using imagesLoaded

Agencies and Freelancers Selling Front-End Modernization

SaaS Vendors Replacing Custom Gallery and Layout Code

How DetectZeStack Detects imagesLoaded

Script Signatures and CDN Fingerprints

API Example: Check a Single Domain for imagesLoaded

API Example: Build a List of Companies Using imagesLoaded

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

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

Turning Detections Into a Prospect List

Get Started

Related Reading

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

Why Find Companies Using WP Engine?

Sales Prospecting for WordPress Agencies and Plugin Vendors

Competitive and Migration Intelligence

How WP Engine Reveals Itself (Detection Signals)

DNS CNAME Records Pointing to *.wpengine.com

WP Engine Cache Headers and Server Fingerprints

Why Header Checks Alone Miss Hardened Sites

Manual Detection Methods (and Their Limits)

Detect WP Engine with the DetectZeStack API

Single Domain Check with /analyze (curl example)

Scanning a Lead List with /analyze/batch

Building a WP Engine Prospect List Workflow

Get Started with a Free API Key

Conclusion

Related Reading

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

DNS Lookup API vs Running `dig` Yourself