DEV Community: MikeL

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

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

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

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

Why Detect React on a Website

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

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

Method 1 — Browser DevTools Console

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

Check for React Global Objects

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

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

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

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

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

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

Inspect the DOM for React Fiber Attributes

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

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

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

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

Method 2 — View Page Source Clues

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

Script Tags and Bundle Filenames

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

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

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

Server-Side Rendered React and Next.js Markers

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

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

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

Method 3 — Browser Extensions

React Developer Tools Extension

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

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

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

DetectZeStack Chrome Extension

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

Method 4 — DetectZeStack API (Programmatic Detection)

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

Single-URL Analysis with curl

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

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

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

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

Reading the API Response

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

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

Key fields to look at:

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

Batch Detection Across Multiple Sites

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

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

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

React vs Next.js — What the Detection Tells You

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

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

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

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

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

Get Started with Programmatic React Detection

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

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

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

How to Detect if a Website Uses Intercom: 5 Methods

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

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

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

Why Detect Intercom on a Website

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

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

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

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

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

Method 1 — Check the Page Source for Intercom Scripts

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

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

What to Look For in the HTML

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

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

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

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

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

Method 2 — Inspect Cookies and Local Storage

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

Intercom Cookies

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

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

Local Storage Entries

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

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

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

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

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

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

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

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

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

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

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

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

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

Method 4 — Check the JavaScript Global Object

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

In the browser console:

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

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

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

You can also extract configuration details:

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

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

Method 5 — Use the DetectZeStack API for Programmatic Detection

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

Single URL Analysis with curl

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

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

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

Batch Detection Across Multiple Sites

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

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

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

Reading the API Response

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

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

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

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

Common Use Cases for Intercom Detection

Competitive Intelligence for Sales Teams

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

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

Security Auditing Third-Party Scripts

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

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

Migration Planning

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

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

Intercom Detection at Scale

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

import requests
import csv
import time

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

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

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

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

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

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

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

time.sleep(0.5)  # respect rate limits

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

Conclusion and Next Steps

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

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

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

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

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

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

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

The Problem With Single-Layer Detection

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

But it misses things:

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

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

The Four Detection Layers

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

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

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

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

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

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

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

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

I maintain 111 DNS signatures mapping CNAME patterns to technologies:

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

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

Layer 3: TLS Certificate Analysis

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

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

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

Layer 4: Custom Header Matching

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

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

These fill gaps where standard fingerprinting falls short.

Deduplication

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

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

What the Output Looks Like

Here's a real scan of stripe.com:

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

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

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

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

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

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

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

Architecture Decisions

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

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

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

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

Try It

The /demo endpoint is free, no signup needed:

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

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

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

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

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

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

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

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

The Full Script

import requests
import sys

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

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

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

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

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

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

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

Save this as scan.py and run it:

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

Sample Output

Here's what you get for stripe.com:

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

  CDN:
    - Cloudflare [dns]

  JavaScript frameworks:
    - React [wappalyzer]

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

  Analytics:
    - Google Analytics [wappalyzer]

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

  Total: 5 technologies detected

What's Happening Under the Hood

The API uses four detection layers:

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

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

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

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

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

Extending It: Batch Analysis

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

import requests

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

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

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

This sends one HTTP request instead of five.

Extending It: Security Scanning with CPE

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

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

This is useful for security audits and compliance checks.

Getting an API Key

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

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

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

I Built an API That Detects 7,200+ Technologies on Any Website — Here's How the Detection Works

MikeL — Mon, 02 Mar 2026 13:59:43 +0000

Every developer has wondered "what is that site built with?" I built an API to answer that question programmatically, and the detection system behind it is more interesting than you'd think.

Here's how it works under the hood.

The Problem

Browser extensions like Wappalyzer can tell you what technologies a website uses. But if you want to check hundreds or thousands of sites programmatically — say, for market research, security audits, or competitive analysis — you need an API.

BuiltWith offers one at $995/month. Wappalyzer's (now owned by Hostinger) starts at $450/month. I wanted something affordable, so I built my own.

The result is DetectZeStack, a Go API that combines four different detection methods to identify technologies on any website.

The Four Detection Layers

A single HTTP request to a website gives you surprisingly little information. To get accurate results, you need to look at multiple signals.

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

This is the heavy hitter. The open-source wappalyzergo library maintains thousands of fingerprint patterns that match against:

HTTP response headers (e.g., X-Powered-By: Express → Node.js + Express)
HTML body content (e.g., <meta name="generator" content="WordPress">)
JavaScript globals (e.g., window.Shopify → Shopify)
Cookie names (e.g., _ga → Google Analytics)

Each pattern has a confidence score. When a site's response matches a known pattern, we know what's behind it.

// The core fingerprinting call
fingerprintsWithInfo := d.wap.FingerprintWithInfo(
    fetchResult.Headers,
    fetchResult.Body,
)

This single function call does most of the work — checking HTTP headers and HTML body against all ~7,200 patterns.

Layer 2: DNS CNAME Resolution (111 signatures)

Here's where it gets interesting. Many hosting platforms and CDNs require you to set a CNAME record pointing to their infrastructure. By resolving a domain's DNS records, you can detect technologies that leave zero traces in HTTP responses.

For example:

example.com → d1234.cloudfront.net → Amazon CloudFront
example.com → example.netlify.app → Netlify
example.com → example.ghost.io → Ghost CMS

// DNS lookup runs in parallel with HTTP fetch
go func() {
    techs := DetectFromDNS(ctx, domain, d.dnsResolver)
    dnsCh <- dnsResult{techs: techs}
}()

This runs concurrently with the HTTP request — no extra latency. I maintain 111 CNAME suffix-to-technology mappings covering CDNs, hosting platforms, email providers, and more.

Layer 3: TLS Certificate Inspection (8 issuers)

The TLS handshake happens before any HTTP data is exchanged, and the certificate issuer tells you something about the infrastructure:

Cloudflare issues its own certs for proxied sites
Amazon certs suggest AWS infrastructure
Google Trust Services suggests Google Cloud
Let's Encrypt is common on self-hosted setups

var tlsSignatures = []TLSSignature{
    {"Cloudflare", "Cloudflare", []string{"CDN"}},
    {"Amazon", "Amazon Web Services", []string{"Cloud hosting"}},
    {"Let's Encrypt", "Let's Encrypt", []string{"SSL/TLS certificate authority"}},
    // ... 5 more
}

During the HTTP fetch, the TLS certificate issuer is extracted from the connection and matched against known issuers.

Layer 4: Custom HTTP Header Matching (3 signatures)

Some platforms add distinctive headers that wappalyzergo doesn't cover yet. Rather than waiting for upstream, I maintain a small set of custom signatures:

var customHeaderSignatures = []HeaderSignature{
    {"X-Railway-Request-Id", "exact", "Railway", []string{"PaaS"}},
    {"X-Amz-Cf-Pop", "exact", "Amazon CloudFront", []string{"CDN"}},
    {"X-Nf-", "prefix", "Netlify", []string{"PaaS", "CDN"}},
}

These catch services like Railway.app (no Wappalyzer entry) and Netlify edge headers.

How It All Fits Together

The detection flow runs in two parallel paths:

Request: "analyze stripe.com"
         |
    +----+----+
    |         |
  HTTP      DNS
  Fetch    Lookup
    |         |
    +- Wappalyzer fingerprinting (headers + body)
    +- Custom header matching
    +- TLS cert issuer extraction
    |         |
    +----+----+
         |
    Deduplicate & merge
         |
    Sort alphabetically
         |
    Return result

DNS and HTTP run concurrently, so total latency is max(http_time, dns_time) rather than the sum. For most sites, results come back in 1-3 seconds.

The deduplication step is important — if Wappalyzer detects "Cloudflare" from a cf-ray header AND the DNS CNAME points to Cloudflare AND the TLS cert is issued by Cloudflare, we only report it once. Multiple detection paths increase confidence without duplicating results.

Real Output

Here's what the API returns for stripe.com:

{
  "domain": "stripe.com",
  "technologies": [
    {
      "name": "Amazon S3",
      "categories": ["CDN"],
      "confidence": 100
    },
    {
      "name": "Amazon Web Services",
      "categories": ["PaaS"],
      "confidence": 100
    },
    {
      "name": "DigiCert",
      "categories": ["SSL/TLS certificate authority"],
      "confidence": 70
    },
    {
      "name": "HSTS",
      "categories": ["Security"],
      "confidence": 100
    },
    {
      "name": "Nginx",
      "categories": ["Web servers", "Reverse proxies"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*"
    }
  ],
  "meta": {
    "status_code": 200,
    "tech_count": 5
  }
}

Notice the cpe field on Nginx — that's a Common Platform Enumeration identifier. It lets you cross-reference detected technologies against the NVD vulnerability database. Not every technology has a CPE, but when one exists, the API includes it.

SSRF Protection

When you build an API that fetches arbitrary URLs, security is critical. Without protection, someone could pass http://169.254.169.254/latest/meta-data/ and read your cloud instance's metadata.

The fetcher validates every URL before making a request:

Parse and normalize the URL
Resolve the domain to IP addresses
Block private/reserved IP ranges (127.x, 10.x, 169.254.x, etc.)
Block non-HTTP(S) schemes
Follow redirects (up to 10) but re-validate each redirect target

This is the boring-but-critical part that you skip at your peril.

Try It Yourself

The API has a free demo endpoint — no signup, no API key:

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

This returns the full detection result. Rate-limited to 20 requests per hour per IP, which is enough to play around with.

For production use, there's a free tier (100 requests/month) and a Pro tier ($9/month for 1,000 requests) on RapidAPI.

What I'd Do Differently

If I were starting over:

Start with DNS detection earlier. I added it late and was surprised how much it catches that HTTP-only detection misses. Ghost blogs, Netlify sites, and many email providers are invisible to Wappalyzer but obvious from DNS.
Build the TLS layer from day one. Same story — the certificate issuer is free information you already receive during the handshake. Not extracting it is leaving data on the table.
Use wappalyzergo, not Wappalyzer's npm package. The Go port is maintained by ProjectDiscovery, compiles to a single binary, and runs faster than the Node.js version. If you're building a service, Go is a solid choice here.

The Stack

Language: Go 1.24
Router: chi
Database: SQLite (yes, in production — it works great for read-heavy workloads)
Detection: wappalyzergo + custom layers
Hosting: Fly.io (single region, single instance)
DNS: Cloudflare

Total monthly hosting cost: ~$5.

If you have questions about the detection approach or want to see how a specific site gets detected, drop a comment — I'll run it through the API and share the results.

Security Audit Any Website's Dependencies with CPE Data

MikeL — Wed, 18 Feb 2026 21:40:23 +0000

Every technology on a website is a potential attack surface. An outdated jQuery version, an unpatched WordPress plugin, a web server with a known CVE — these are the entry points attackers look for.

The problem is visibility. How do you know what technologies a website runs, and which have known vulnerabilities?

DetectZeStack returns CPE (Common Platform Enumeration) identifiers for every detected technology. CPE is the standard naming scheme used by NIST's National Vulnerability Database (NVD) to link software products to their known vulnerabilities (CVEs).

How CPE-Based Security Auditing Works

Detect technologies — scan a website to identify all tech
Extract CPE IDs — each technology includes its CPE identifier
Query NVD — look up each CPE for known CVEs
Assess risk — prioritize by CVSS score

Step 1: Detect Technologies with CPE Data

curl -s "https://detectzestack.fly.dev/analyze?url=example.com" \
  -H "X-Api-Key: YOUR_KEY" | jq '.technologies[] | {name, cpe}'

Example response:

[
  { "name": "Nginx", "cpe": "cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*" },
  { "name": "jQuery", "cpe": "cpe:2.3:a:jquery:jquery:*:*:*:*:*:*:*:*" },
  { "name": "WordPress", "cpe": "cpe:2.3:a:wordpress:wordpress:*:*:*:*:*:*:*:*" }
]

What's a CPE? It's a structured naming scheme for IT products. cpe:2.3:a:wordpress:wordpress:* means "application, vendor wordpress, product wordpress, any version." The NVD uses CPEs to link products to CVE entries.

Step 2: Query the NVD for Vulnerabilities

Here's a Python script that takes DetectZeStack output and checks each technology for known vulnerabilities:

import requests
import time

DETECTZESTACK_URL = "https://detectzestack.fly.dev/analyze"
NVD_API_URL = "https://services.nvd.nist.gov/rest/json/cves/2.0"
API_KEY = "your-detectzestack-key"

def audit_website(domain):
    # Detect technologies
    resp = requests.get(DETECTZESTACK_URL, params={"url": domain}, headers={
        "X-Api-Key": API_KEY
    })
    techs = resp.json().get("technologies", [])

    findings = []
    for tech in techs:
        cpe = tech.get("cpe")
        if not cpe:
            continue

        # Query NVD
        nvd_resp = requests.get(NVD_API_URL, params={
            "cpeName": cpe,
            "resultsPerPage": 10
        })
        time.sleep(0.6)  # NVD rate limit

        vulns = nvd_resp.json().get("vulnerabilities", [])
        if vulns:
            findings.append({
                "technology": tech["name"],
                "cpe": cpe,
                "cve_count": len(vulns),
                "top_cves": [v["cve"]["id"] for v in vulns[:5]]
            })

    return findings

findings = audit_website("target-site.com")
for f in findings:
    print(f"{f['technology']}: {f['cve_count']} known vulnerabilities")
    for cve in f['top_cves']:
        print(f"  - {cve}")

Step 3: Automate Continuous Monitoring

Set up webhook alerts for real-time tech change notifications:

curl -X POST "https://detectzestack.fly.dev/webhooks" \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "domain": "app.yourcompany.com",
    "webhook_url": "https://your-siem.com/webhook/techstack",
    "secret": "hmac-secret-for-verification"
  }'

When a technology changes on a monitored domain, you'll receive a webhook. Feed this into your vulnerability management pipeline to check for newly introduced risks.

Practical Use Cases

Vendor Risk Assessment: Before onboarding a SaaS vendor, audit their website. Outdated frameworks or missing security headers are red flags.

Supply Chain Monitoring: Track tech changes across critical suppliers. If a partner drops HTTPS or switches CDNs, you want to know.

Penetration Test Recon: Start engagements with a comprehensive technology inventory. Four detection layers (HTTP, DNS, TLS, headers) surface infrastructure that manual inspection misses.

Compliance Reporting: Generate evidence that your web properties use current, patched technologies for SOC 2, ISO 27001, or PCI DSS audits.

Why Not Just Use a Vulnerability Scanner?

Traditional scanners (Nessus, Qualys) require network access and authenticated scans. DetectZeStack works from the outside — you can audit any public website, including vendor sites you don't control. They're complementary tools.

Cost

Manual vendor security assessments cost $500-2,000 per vendor. Automated tools like BitSight charge $15,000-50,000/year.

With DetectZeStack at $5/month (5,000 requests), you can audit 5,000 domains monthly. That's enterprise-grade coverage at indie pricing.

Get your free API key — 100 requests/month, no credit card required.

How do you handle external dependency auditing? I'd love to hear your approach in the comments.

How to Build a Lead Enrichment Pipeline with Tech Detection

MikeL — Wed, 18 Feb 2026 21:39:35 +0000

Your CRM has thousands of leads. Names, emails, company URLs. But without knowing what technologies those companies use, your sales team is shooting in the dark.

Tech stack data transforms cold outreach into relevant conversations. If you're selling a Shopify app, you only want leads running Shopify. If you offer WordPress security, you need WordPress sites.

In this guide, we'll build a lead enrichment pipeline that takes a list of company domains and enriches each one with technology data using the DetectZeStack API.

The Pipeline

Export leads from your CRM (just the domain column)
Batch analyze with DetectZeStack (10 domains per request)
Filter and score leads by technology match
Push enriched data back to your CRM

Step 1: Prepare Your Domain List

Export your leads as a CSV. The only required field is the company's domain:

domains.csv:
company,domain
Acme Corp,acmecorp.com
Globex Inc,globex.io
Initech,initech.com

Step 2: Batch Analyze

The /analyze/batch endpoint processes up to 10 URLs concurrently. Here's a Python script that reads your CSV and enriches each domain:

import csv
import json
import requests
import time

API_URL = "https://detectzestack.fly.dev/analyze/batch"
API_KEY = "your-api-key"
BATCH_SIZE = 10

def enrich_domains(csv_path):
    with open(csv_path) as f:
        rows = list(csv.DictReader(f))

    enriched = []

    for i in range(0, len(rows), BATCH_SIZE):
        batch = rows[i:i + BATCH_SIZE]
        urls = [row["domain"] for row in batch]

        resp = requests.post(API_URL, json={"urls": urls}, headers={
            "X-Api-Key": API_KEY,
            "Content-Type": "application/json"
        })
        results = resp.json().get("results", [])

        for row, result in zip(batch, results):
            techs = [t["name"] for t in result.get("technologies", [])]
            categories = set()
            for t in result.get("technologies", []):
                categories.update(t.get("categories", []))

            row["technologies"] = ", ".join(techs)
            row["categories"] = ", ".join(categories)
            row["tech_count"] = len(techs)
            enriched.append(row)

        time.sleep(1)  # Respect rate limits

    return enriched

results = enrich_domains("domains.csv")

For 1,000 leads, that's 100 API calls — well within the Pro plan's 5,000 monthly limit.

Step 3: Filter and Score

Now filter leads by relevance:

# Find all Shopify stores
shopify_leads = [r for r in results if "Shopify" in r["technologies"]]

# Find WordPress sites without a CDN
wp_no_cdn = [
    r for r in results
    if "WordPress" in r["technologies"]
    and not any(cdn in r["technologies"]
        for cdn in ["Cloudflare", "Fastly", "CloudFront"])
]

# Score leads by tech stack overlap with your ideal customer
TARGET_TECHS = {"React", "Next.js", "Vercel", "Stripe"}

for lead in results:
    lead_techs = set(lead["technologies"].split(", "))
    lead["score"] = len(lead_techs & TARGET_TECHS)

results.sort(key=lambda r: r["score"], reverse=True)

Pro tip: Use the /compare endpoint to compare a prospect's stack against your best customer's stack. High overlap = high-probability close.

Step 4: Push to Your CRM

Most CRMs support custom fields. Once technology data is in your CRM, you can:

Create smart lists filtered by technology ("All Shopify + Klaviyo leads")
Trigger automated sequences based on tech stack match
Personalize email templates with technology references
Route leads to the right sales rep based on tech expertise

Real-World Use Cases

SaaS Sales: Find companies using a competitor's product. "I noticed you're using [Competitor] — here's how we compare."

Agency Prospecting: Find sites on outdated tech. "Your site runs jQuery 1.x — we can modernize it."

Platform Partnerships: Find companies in your ecosystem. "You're on Vercel + Next.js — our integration is built for your stack."

Security Services: Identify sites with known vulnerable technologies using CPE data. Offer remediation.

Keeping Data Fresh

Tech stacks change. Set up webhook alerts for real-time monitoring:

curl -X POST "https://detectzestack.fly.dev/webhooks" \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "domain": "important-prospect.com",
    "webhook_url": "https://your-app.com/webhook",
    "secret": "your-hmac-secret"
  }'

Cost Comparison

Enriching 1,000 leads monthly:

Tool	Monthly Cost
BuiltWith	$995/mo
Wappalyzer	$450/mo
DetectZeStack	$5/mo

At $5/month for 5,000 requests, you can enrich your entire pipeline for less than a single month of the cheapest alternative. See our full comparison for details.

Get your free API key — 100 requests/month, no credit card required.

What's your lead enrichment workflow? I'd love to hear how you're using tech detection in the comments.

BuiltWith vs Wappalyzer vs DetectZeStack: Which Tech Detection Tool Is Right for You?

MikeL — Wed, 18 Feb 2026 21:35:46 +0000

If you need to detect what technologies a website uses, you've probably come across BuiltWith and Wappalyzer. They've been around for years and dominate the space. But they were built for a different era — one where $300+/month for API access was the only option.

I built DetectZeStack as a developer-first alternative. In this post, I'll compare all three honestly — including where each tool excels and falls short.

Quick Comparison

Feature	BuiltWith	Wappalyzer	DetectZeStack
Starting price	$295/mo	$250/mo	Free (100 req/mo)
API access	$995/mo	$450/mo	$5/mo (5K requests)
Technology signatures	~111,000	~8,000	3,500+
Real-time analysis	Cached/crawled	Yes	Yes
Detection method	Web crawling	HTTP + HTML	HTTP + HTML + DNS + TLS
DNS/TLS detection	No	No	Yes
CPE identifiers	No	No	Yes
Stack comparison	No	No	Yes
Webhook alerts	No	No	Yes
Free tier	No	Browser extension only	100 req/mo

BuiltWith: The Enterprise Standard

BuiltWith has been around since 2007 and has the largest technology database — over 111,000 signatures. It's the go-to for enterprise sales teams and market researchers.

Strengths:

Massive database: 111K+ technologies, including obscure plugins and analytics tools
Historical data going back years
Built-in lead list generation filtered by technology
Market share reports across millions of sites

Weaknesses:

Starts at $295/month, API requires Pro at $995/month
Stale data — crawls periodically, not on demand
No real-time analysis — only reports what it found during its last crawl
Complex pricing tiers

Best for: Enterprise sales teams with budget for historical data and lead lists.

Wappalyzer: The Developer Favorite

Wappalyzer started as an open-source browser extension in 2009. It was acquired by Sindup in August 2023, and the open-source repository was archived.

Strengths:

Well-known brand with strong community
~8,000 well-maintained technology signatures
Free browser extension for one-off lookups
CRM integrations (HubSpot, Salesforce, Pipedrive)

Weaknesses:

API starts at $250/month (Starter), $450/month (Business)
No longer open source — fingerprints are closed
Frontend-only detection (HTTP + HTML) — misses infrastructure
No CPE data for security use cases
Restrictive rate limits on paid plans

Best for: Teams that need CRM integrations and are in the Wappalyzer ecosystem.

DetectZeStack: The Developer-First API

DetectZeStack was built from the ground up as a REST API. No dashboards, no CRM plugins — just a fast, well-documented API that returns structured JSON.

Strengths:

Free tier (100 req/mo), paid starts at $5/mo for 5K requests
Multi-layer detection: Wappalyzer fingerprinting + DNS CNAME + TLS certificates + custom headers
CPE identifiers for mapping to the NVD vulnerability database
/compare endpoint for side-by-side stack analysis
Webhook alerts for tech change monitoring
Real-time analysis with 24-hour caching

Weaknesses:

Smaller signature database (3,500+ vs 111K)
No historical data (tracks changes going forward, no backfill)
No browser extension — API-only (with a live demo)
New product (launched Feb 2026)

Best for: Developers who need programmatic tech detection at a reasonable price, especially security teams (CPE data).

Pricing: The Elephant in the Room

For 5,000 API requests per month:

	BuiltWith	Wappalyzer	DetectZeStack
Monthly cost	$995	$450	$5
Annual cost	$11,940	$5,400	$60
Cost per request	$0.199	$0.090	$0.001

At 25,000 requests/month, DetectZeStack costs $15/month vs $995+ for BuiltWith and $450+ for Wappalyzer. That's a 60x-90x price difference.

Detection Accuracy: A Practical Test

We ran all three tools against github.com:

Technology	BuiltWith	Wappalyzer	DetectZeStack
Ruby on Rails	Yes	Yes	Yes
React	Yes	Yes	Yes
Nginx	Yes	Yes	Yes
Fastly CDN	No	No	Yes (DNS CNAME)
DigiCert TLS	No	No	Yes (TLS cert)
CPE identifiers	No	No	Yes

All three catch major technologies. DetectZeStack's DNS and TLS layers add infrastructure visibility that HTTP-only tools miss. BuiltWith detects more niche technologies thanks to its larger database.

Try It Yourself

curl -s "https://detectzestack.fly.dev/analyze?url=your-site.com" \
  -H "X-Api-Key: YOUR_KEY" | jq '.technologies[].name'

Compare results against BuiltWith's free lookup and the Wappalyzer extension. For most developer use cases, DetectZeStack catches everything you need — plus infrastructure — at a fraction of the cost.

Get your free API key on RapidAPI — 100 requests/month, no credit card required.

What tech detection tools do you use? I'd love to hear about your use cases in the comments.

Detect Any Website's Tech Stack With a Single API Call

MikeL — Wed, 18 Feb 2026 21:34:23 +0000

Knowing what technologies a website uses is valuable for competitive intelligence, security audits, lead generation, and vendor evaluation. But manually inspecting HTTP headers, HTML source, and DNS records is tedious and incomplete.

I built DetectZeStack to solve this with a single API call that runs four detection layers simultaneously and returns a comprehensive technology profile.

The Four Detection Layers

1. Wappalyzer Fingerprinting

3,500+ technology signatures matching HTTP headers, HTML patterns, JavaScript variables, cookies, and meta tags.

2. DNS CNAME Analysis

29 DNS signatures identifying CDNs and infrastructure: CloudFront, Fastly, Cloudflare, Akamai, Vercel, Netlify, and more.

3. TLS Certificate Inspection

8 certificate issuer patterns detecting CDN and security providers from their TLS certificates.

4. Custom Header Matching

Server headers, X-Powered-By, and custom response headers identifying frameworks and platforms.

These layers complement each other. Wappalyzer catches front-end frameworks and CMS platforms. DNS and TLS catch infrastructure that's invisible to HTML analysis. Together they paint a complete picture.

Quick Start

Analyze any website with a single GET request:

curl "https://detectzestack.fly.dev/analyze?url=stripe.com" \
  -H "X-Api-Key: YOUR_KEY"

Response:

{
  "domain": "stripe.com",
  "url": "https://stripe.com",
  "technologies": [
    {
      "name": "Cloudflare",
      "categories": ["CDN"],
      "confidence": 100
    },
    {
      "name": "React",
      "categories": ["JavaScript frameworks"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:facebook:react:*:*:*:*:*:*:*:*"
    },
    {
      "name": "Next.js",
      "categories": ["Static site generator"],
      "confidence": 100
    },
    {
      "name": "Nginx",
      "categories": ["Web servers"],
      "confidence": 100
    }
  ],
  "meta": {
    "status_code": 200,
    "tech_count": 4
  },
  "cached": false,
  "response_ms": 1240
}

Each technology comes with metadata: description, official website, icon, and CPE identifier (for cross-referencing with vulnerability databases).

Batch Analysis

Need to analyze multiple sites at once? The /analyze/batch endpoint handles up to 10 URLs in a single request with concurrent processing:

curl -X POST "https://detectzestack.fly.dev/analyze/batch" \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["stripe.com", "shopify.com", "vercel.com"]}'

All URLs are analyzed concurrently, so the total time is roughly the same as analyzing a single slow site.

Comparing Tech Stacks

The /compare endpoint shows shared and unique technologies across multiple sites:

curl -X POST "https://detectzestack.fly.dev/compare" \
  -H "X-Api-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["github.com", "gitlab.com"]}'

The response includes shared technologies (used by both) and unique technologies per domain -- useful for competitive analysis.

Practical Applications

Lead Generation -- Filter prospects by technology. Selling a Shopify app? Find sites running Shopify.

Security Auditing -- Combine tech detection with CPE identifiers to check each technology against the NVD vulnerability database.

Migration Planning -- Document a complete tech stack programmatically before migrating.

Market Research -- Analyze hundreds of sites in a market segment to understand technology adoption trends.

Try It Free

100 requests/month on the free tier. No credit card required. Paid plans from $5/mo.

Live Demo -- try it without signing up
Get an API Key on RapidAPI
OpenAPI Spec

I'd love to hear what use cases you'd find most valuable. Drop a comment below or reach out on X (@DetectZeStack).

Why Single-Layer Tech Detection Misses Half the Stack (And How to Fix It)

MikeL — Mon, 16 Feb 2026 17:40:40 +0000

Most tech stack detection tools use a single method: they download a webpage's HTML and match it against a pattern library. Wappalyzer checks for wp-content in URLs to detect WordPress. BuiltWith looks for _next/ paths to identify Next.js.

This works well for front-end technologies. But it completely misses the infrastructure layer — CDNs, hosting providers, security services, and server-side platforms that never expose themselves in HTML.

In this post, I'll walk through why single-layer detection fails, what you're missing, and how combining multiple detection methods gives you the full picture.

The Problem: HTML-Only Detection Has Blind Spots

Here's what a typical Wappalyzer-style scan returns for a production website:

{
  "technologies": [
    {"name": "React", "confidence": 100},
    {"name": "Webpack", "confidence": 100},
    {"name": "Google Analytics", "confidence": 100}
  ]
}

Three technologies. Looks complete, right?

But this site is actually running behind Cloudflare's CDN, using Let's Encrypt certificates, hosted on Vercel, and serving responses through nginx. None of that shows up in the HTML.

That's because HTML-level detection only sees what the browser sees: script tags, meta elements, cookies, and URL patterns. Everything happening at the DNS, TLS, and HTTP layer is invisible to it.

Layer 1: Wappalyzer Fingerprinting (The Baseline)

HTML fingerprinting is still the foundation. Libraries like wappalyzergo maintain 3,500+ technology signatures that match against:

HTML content and DOM structure
JavaScript global variables
Cookie names and values
URL patterns (/wp-content/, /_next/, /assets/)
Meta tags and headers referenced in the page

This catches most front-end frameworks, CMS platforms, analytics tools, and JavaScript libraries. For many use cases, it's sufficient.

But if you're doing security audits, competitive analysis, or lead enrichment, you need the full stack — not just what's visible in the DOM.

Layer 2: DNS CNAME Analysis

Every website's DNS records tell a story. When a site uses Cloudflare, its CNAME records typically point to something like cdn.cloudflare.net. Vercel uses cname.vercel-dns.com. AWS CloudFront uses cloudfront.net.

Here's how DNS detection works in practice:

// Simplified DNS CNAME lookup
cnames, err := net.LookupCNAME(domain)
// Then match against known patterns:
// "cloudflare.net"  → Cloudflare
// "fastly.net"      → Fastly
// "vercel-dns.com"  → Vercel
// "amazonaws.com"   → AWS

This catches infrastructure that's completely invisible to HTML scanning:

CNAME Pattern	Technology
`*.cloudflare.net`	Cloudflare CDN
`*.fastly.net`	Fastly
`*.vercel-dns.com`	Vercel
`*.amazonaws.com`	AWS (S3, CloudFront, ELB)
`*.azurewebsites.net`	Microsoft Azure
`*.herokuapp.com`	Heroku
`*.netlify.app`	Netlify
`*.shopify.com`	Shopify

DNS lookups add roughly 20-50ms to a detection request, but the intelligence gained is significant. You now know the hosting and CDN layer — information that HTML detection simply cannot provide.

Layer 3: TLS Certificate Inspection

TLS certificates reveal which certificate authority (CA) a site trusts, which often maps directly to their security infrastructure.

// Connect to the site and inspect the TLS certificate
conn, err := tls.Dial("tcp", domain+":443", &tls.Config{})
cert := conn.ConnectionState().PeerCertificates[0]
issuer := cert.Issuer.Organization[0]
// Match against known issuers:
// "Let's Encrypt"           → Let's Encrypt
// "Cloudflare, Inc."        → Cloudflare SSL
// "Amazon"                  → AWS Certificate Manager
// "DigiCert Inc"            → DigiCert

This detection layer tells you:

Let's Encrypt — free automated certificates, common with smaller deployments
Cloudflare, Inc. — using Cloudflare's SSL proxy (even if DNS doesn't show it)
Amazon — AWS Certificate Manager, confirms AWS infrastructure
DigiCert / Sectigo — enterprise-grade certificates, signals larger organization

TLS inspection is especially useful for security audits. Knowing the certificate authority and expiration helps assess a site's security posture.

Layer 4: HTTP Header Matching

HTTP response headers are another goldmine. Many servers and platforms identify themselves through headers that never appear in the HTML:

Server: nginx/1.24.0
X-Powered-By: Express
X-Vercel-Id: iad1::abcde-123456
CF-Cache-Status: HIT
X-Cache: Hit from cloudfront

Custom header patterns I match against:

Header	Value Pattern	Technology
`Server`	`nginx`	nginx
`Server`	`Apache`	Apache
`X-Powered-By`	`Express`	Express.js
`X-Powered-By`	`PHP`	PHP
`CF-Cache-Status`	(any)	Cloudflare
`X-Vercel-Id`	(any)	Vercel
`X-Amz-Cf-Id`	(any)	AWS CloudFront

Headers are free — you already have the HTTP response from the HTML scan, so this adds zero latency.

Putting It All Together

When you run all four layers simultaneously, the detection picture changes dramatically. Here's a real comparison:

HTML-only detection:

React, Webpack, Google Analytics

Four-layer detection:

React, Webpack, Google Analytics (HTML)
Cloudflare CDN (DNS)
Cloudflare SSL (TLS)
nginx (HTTP headers)
Vercel (HTTP headers)

That's 7 technologies vs. 3 — more than double the coverage.

Adding CPE Identifiers for Security

Each detected technology gets a CPE (Common Platform Enumeration) identifier where available. CPE is a standardized naming scheme for software, maintained by NIST.

For example:

nginx → cpe:2.3:a:f5:nginx:*
Apache → cpe:2.3:a:apache:http_server:*
WordPress → cpe:2.3:a:wordpress:wordpress:*

With CPE identifiers, you can query the National Vulnerability Database to find known CVEs for every technology in a site's stack. This turns tech detection into a security audit tool.

Performance: Why Caching Matters

Multi-layer detection is slower than HTML-only scanning. DNS lookups, TLS handshakes, and the HTTP request itself all add latency. A typical 4-layer scan takes 2-5 seconds.

That's why caching is critical. I use a 24-hour cache keyed on the post-redirect domain (not the input URL — important for sites that redirect). Cached responses return in under 5ms and don't count against API quotas.

The key insight: cache on the final domain after following redirects. If someone queries example.com and it redirects to www.example.com, the cache key should be www.example.com. Otherwise you'll get cache misses for the same site.

The Architecture

The whole system is built in Go with:

chi router for HTTP routing
SQLite for caching, rate limiting, and usage tracking
wappalyzergo for HTML fingerprinting
net stdlib for DNS lookups
crypto/tls stdlib for certificate inspection

It runs on a single Fly.io machine. Total codebase is about 3,000 lines of Go.

I chose Go because:

Excellent concurrency — all 4 detection layers run simultaneously using goroutines
Fast TLS and DNS operations via the standard library
Single binary deployment — no runtime dependencies
Low memory footprint for a single-machine deployment

Try It Yourself

I built DetectZeStack as a REST API that implements all four detection layers. You can try the live demo on the homepage — no signup required.

The API also supports:

Batch analysis: up to 10 URLs per request
Stack comparison: see shared vs. unique technologies across sites
Webhook alerts: get notified when a domain is analyzed, with HMAC-signed payloads

Free tier is 100 requests/month.

What detection methods have you found useful for identifying website technologies? I'd love to hear about approaches I haven't considered.

How to Detect Vulnerable Technologies on Any Website Using CPE Identifiers

MikeL — Wed, 11 Feb 2026 21:59:21 +0000

When a new CVE drops and your boss asks "are we running that?" — how fast can you answer?

Most teams scramble through Confluence pages, Slack threads, and half-updated spreadsheets. But there's a better approach: automated technology detection with CPE identifiers that plug directly into vulnerability databases.

In this post, I'll show you how to detect what technologies a website is running and get machine-readable CPE strings you can cross-reference with NIST's National Vulnerability Database (NVD).

What Are CPE Identifiers?

CPE (Common Platform Enumeration) is a standardized naming scheme for IT products. It looks like this:

cpe:2.3:a:apache:http_server:2.4.51:*:*:*:*:*:*:*

The NVD uses CPEs to map CVEs to affected software. If you know the CPE of what you're running, you can instantly look up every known vulnerability for that exact product and version.

The problem? Most teams don't maintain an accurate inventory of what technologies their web properties are running.

Automated Detection with DetectZeStack

DetectZeStack is a REST API that analyzes any website and returns the full technology stack — including CPE identifiers where available. It combines multiple detection methods:

Wappalyzer fingerprinting — 3,500+ technology signatures matched against HTTP headers, HTML content, and JavaScript patterns
DNS CNAME analysis — 29 infrastructure signatures (CloudFront, Fastly, Akamai, Netlify, Vercel, etc.)
TLS certificate inspection — 8 certificate authority signatures (Cloudflare, DigiCert, Let's Encrypt, etc.)
Custom header matching — security headers like HSTS, server identification

Quick Example

curl "https://detectzestack.p.rapidapi.com/analyze?url=example.com" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"

Response:

{
  "domain": "example.com",
  "technologies": [
    {
      "name": "Nginx",
      "categories": ["Web servers"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:nginx:nginx:*:*:*:*:*:*:*:*"
    },
    {
      "name": "jQuery",
      "categories": ["JavaScript libraries"],
      "confidence": 100,
      "cpe": "cpe:2.3:a:jquery:jquery:*:*:*:*:*:*:*:*"
    }
  ]
}

Each technology with a known CPE includes it in the response. You can then query the NVD API directly:

curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:nginx:nginx:*"

Building a Vulnerability Scanner

Here's a practical Python script that ties it together — detect technologies, extract CPEs, and check for known vulnerabilities:

import requests
import time

RAPIDAPI_KEY = "your_key_here"

def detect_stack(url):
    resp = requests.get(
        "https://detectzestack.p.rapidapi.com/analyze",
        params={"url": url},
        headers={
            "X-RapidAPI-Key": RAPIDAPI_KEY,
            "X-RapidAPI-Host": "detectzestack.p.rapidapi.com"
        }
    )
    return resp.json()

def check_cves(cpe_name):
    resp = requests.get(
        "https://services.nvd.nist.gov/rest/json/cves/2.0",
        params={"cpeName": cpe_name}
    )
    data = resp.json()
    return data.get("vulnerabilities", [])

# Detect technologies
result = detect_stack("yoursite.com")

for tech in result["technologies"]:
    cpe = tech.get("cpe")
    if not cpe:
        continue

    print(f"\n{tech['name']} ({cpe})")

    vulns = check_cves(cpe)
    if vulns:
        print(f"  Found {len(vulns)} known CVEs:")
        for v in vulns[:5]:
            cve = v["cve"]
            severity = "N/A"
            metrics = cve.get("metrics", {})
            if "cvssMetricV31" in metrics:
                severity = metrics["cvssMetricV31"][0]["cvssData"]["baseSeverity"]
            print(f"    {cve['id']} - {severity}")
    else:
        print("  No known CVEs")

    time.sleep(1)  # Rate limit NVD API

Use Cases for Security Teams

1. Asset inventory — Scan all your public-facing domains to build a technology inventory. Use the /analyze/batch endpoint to check up to 10 URLs per request.

2. Continuous monitoring — Set up webhook subscriptions to get notified every time a domain is analyzed. Track technology changes over time with the /history endpoint.

3. Vendor risk assessment — Before onboarding a third-party vendor, scan their web properties. Know what they're running before signing the contract.

4. Incident response — When a new CVE is published, immediately scan your domains to check for affected technologies. The 24-hour cache means repeated checks are instant and free.

Try It Out

You can test DetectZeStack right now — no signup required. Visit detectzestack.fly.dev and use the live demo to analyze any website.

For API access, grab a free key on RapidAPI (100 requests/month, no credit card required).

What security automation workflows are you building? I'd love to hear how you're using technology detection in your security pipeline. Drop a comment below.

3 Ways to Use a Tech Stack Detection API: Competitive Analysis, Lead Enrichment & Security Auditing

MikeL — Wed, 11 Feb 2026 19:51:51 +0000

Knowing what technologies power a website isn't just a curiosity — it's actionable intelligence. Whether you're sizing up competitors, qualifying sales leads, or auditing your own security posture, a tech stack detection API can automate what used to take hours of manual inspection.

In this post, I'll walk through three real-world use cases with Python code examples using the DetectZeStack API.

1. Competitive Analysis

The Problem

You need to understand what technologies your competitors are using — their frontend framework, hosting provider, analytics tools, CDN — but manually inspecting source code and HTTP headers across dozens of sites is tedious and error-prone.

The Solution

Batch compare competitors in one call:

import requests

headers = {
    "X-RapidAPI-Key": "YOUR_API_KEY",
    "X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
    "Content-Type": "application/json"
}

# Compare your site against competitors
response = requests.post(
    "https://detectzestack.p.rapidapi.com/compare",
    headers=headers,
    json={"urls": ["yoursite.com", "competitor1.com", "competitor2.com"]}
)

data = response.json()
print("Technologies ALL sites share:", data["shared"])

for domain in data["domains"]:
    print(f"\n{domain['domain']}:")
    print(f"  Total: {len(domain['technologies'])} technologies")
    print(f"  Unique: {domain['unique']}")

Track competitor changes over time:

Set up webhooks for competitor domains. Every time someone analyzes them, you'll receive a notification with their current tech stack — making it easy to spot when competitors adopt new frameworks or switch providers.

Example Insights

"Competitor X switched from Heroku to AWS last month"
"3 of 5 competitors use Next.js — industry trend?"
"Competitor Y added Cloudflare CDN — they're scaling"

2. Lead Enrichment & Sales Intelligence

The Problem

Your sales team has a list of prospect companies but no insight into their technical sophistication. Cold outreach about "infrastructure optimization" falls flat when you don't know if they're on Heroku or bare-metal Kubernetes.

The Solution

Enrich CRM leads with technology data:

import requests

headers = {
    "X-RapidAPI-Key": "YOUR_API_KEY",
    "X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
    "Content-Type": "application/json"
}

# Your prospect list
prospects = ["prospect1.com", "prospect2.com", "prospect3.com",
             "prospect4.com", "prospect5.com"]

# Batch analyze (up to 10 at a time)
response = requests.post(
    "https://detectzestack.p.rapidapi.com/analyze/batch?format=csv",
    headers=headers,
    json={"urls": prospects}
)

# Save CSV directly to file for CRM import
with open("enriched_leads.csv", "w") as f:
    f.write(response.text)

Segment leads by technology:

# Find all prospects using Shopify (potential e-commerce migration targets)
response = requests.post(
    "https://detectzestack.p.rapidapi.com/analyze/batch",
    headers=headers,
    json={"urls": prospects}
)

shopify_users = []
for item in response.json()["results"]:
    if item.get("result"):
        tech_names = [t["name"] for t in item["result"]["technologies"]]
        if "Shopify" in tech_names:
            shopify_users.append(item["result"]["domain"])

print(f"Prospects using Shopify: {shopify_users}")

Example Insights

Segment leads: "Companies using WordPress" vs "Companies using custom React apps" need different pitches
Identify upsell opportunities: "They use basic shared hosting — ready for cloud migration"
Qualify leads: "They already use AWS — likely technical enough for our developer tool"

3. Security Auditing

The Problem

Your security team needs to inventory the technologies across your organization's web properties. Outdated frameworks, known-vulnerable libraries, and misconfigured servers need to be identified before attackers find them.

The Solution

Scan all company domains:

import requests

headers = {
    "X-RapidAPI-Key": "YOUR_API_KEY",
    "X-RapidAPI-Host": "detectzestack.p.rapidapi.com",
    "Content-Type": "application/json"
}

company_domains = [
    "company.com", "app.company.com", "docs.company.com",
    "blog.company.com", "status.company.com"
]

response = requests.post(
    "https://detectzestack.p.rapidapi.com/analyze/batch",
    headers=headers,
    json={"urls": company_domains}
)

for item in response.json()["results"]:
    if item.get("result"):
        domain = item["result"]["domain"]
        for tech in item["result"]["technologies"]:
            # Flag technologies with CPE identifiers
            # (can be cross-referenced with CVE databases)
            if tech.get("cpe"):
                print(f"[CPE] {domain}: {tech['name']} — {tech['cpe']}")

Use CPE identifiers for vulnerability lookups:

The API returns CPE (Common Platform Enumeration) identifiers when available. These can be cross-referenced with the NVD (National Vulnerability Database) to find known CVEs:

cpe:2.3:a:facebook:react:*:*:*:*:*:*:*:*
cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*
cpe:2.3:a:jquery:jquery:*:*:*:*:*:*:*:*

Monitor for technology changes:

Set up webhooks on critical domains. If someone adds a new analytics script or swaps out the CDN, you'll know immediately.

Example Insights

"blog.company.com is running jQuery 2.x — known XSS vulnerabilities"
"staging.company.com exposes Nginx version in headers — information leak"
"marketing site switched SSL providers without security team approval"

Which Endpoints for Which Use Case

Use Case	Primary Endpoint	Also Useful
Competitive analysis	`POST /compare`	`GET /history`, `POST /webhooks`
Lead enrichment	`POST /analyze/batch`	`GET /analyze` (one-off lookups)
Security auditing	`POST /analyze/batch`	`GET /history`, `POST /webhooks`
Technology trends	`GET /history`	`POST /compare`
Change monitoring	`POST /webhooks`	`GET /history`

Get started free (100 requests/month, no credit card): DetectZeStack on RapidAPI

DetectZeStack detects 3,800+ technologies using wappalyzer fingerprinting, DNS analysis, TLS certificates, and custom header matching.

DEV Community: MikeL

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

Why Detect React on a Website

Method 1 — Browser DevTools Console

Check for React Global Objects

Inspect the DOM for React Fiber Attributes

Method 2 — View Page Source Clues

Script Tags and Bundle Filenames

Server-Side Rendered React and Next.js Markers

Method 3 — Browser Extensions

React Developer Tools Extension

DetectZeStack Chrome Extension

Method 4 — DetectZeStack API (Programmatic Detection)

Single-URL Analysis with curl

Reading the API Response

Batch Detection Across Multiple Sites

React vs Next.js — What the Detection Tells You

Get Started with Programmatic React Detection

Related Reading

How to Detect if a Website Uses Intercom: 5 Methods

Why Detect Intercom on a Website

Method 1 — Check the Page Source for Intercom Scripts

What to Look For in the HTML

Method 2 — Inspect Cookies and Local Storage

Intercom Cookies

Local Storage Entries

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

Method 4 — Check the JavaScript Global Object

Method 5 — Use the DetectZeStack API for Programmatic Detection

Single URL Analysis with curl

Batch Detection Across Multiple Sites

Reading the API Response

Common Use Cases for Intercom Detection

Competitive Intelligence for Sales Teams

Security Auditing Third-Party Scripts

Migration Planning

Intercom Detection at Scale

Conclusion and Next Steps

Related Reading

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

The Problem With Single-Layer Detection

The Four Detection Layers

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

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

Layer 3: TLS Certificate Analysis

Layer 4: Custom Header Matching

Deduplication

What the Output Looks Like

Architecture Decisions

Try It

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

The Full Script

Sample Output

What's Happening Under the Hood

Extending It: Batch Analysis

Extending It: Security Scanning with CPE

Getting an API Key

I Built an API That Detects 7,200+ Technologies on Any Website — Here's How the Detection Works

The Problem

The Four Detection Layers

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

Layer 2: DNS CNAME Resolution (111 signatures)

Layer 3: TLS Certificate Inspection (8 issuers)

Layer 4: Custom HTTP Header Matching (3 signatures)

How It All Fits Together

Real Output

SSRF Protection

Try It Yourself

What I'd Do Differently

The Stack

Security Audit Any Website's Dependencies with CPE Data

How CPE-Based Security Auditing Works

Step 1: Detect Technologies with CPE Data

Step 2: Query the NVD for Vulnerabilities

Step 3: Automate Continuous Monitoring

Practical Use Cases

Why Not Just Use a Vulnerability Scanner?

Cost

How to Build a Lead Enrichment Pipeline with Tech Detection

The Pipeline