WhatRuns Alternative API: 4 Options for Programmatic Detection

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.

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.

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.