StackScope Data

Machine access to the StackScope corpus: what just launched, and what it was built with.

See plans and pricing Read the API reference

What people use this for

A site that launched last week is still choosing its suppliers. Analytics, email, hosting and the payment provider are often still unsettled a month in.

Vendors watch a competitor: a standing watch on another tool's technology reports each new launch shipping with it, in the week the choice was made instead of at renewal. Agencies run it the other way round and pull the new sites in their own country running the stack they work in, young enough that nobody has been appointed yet. Analysts want the shape more than the rows, and track how the share of new launches on a given framework moves month to month, measured on a population that is genuinely new. Inside a product, a lookup on a signup's domain returns its stack, hosting and launch date in one call, which is enough to route or score an account before anyone speaks to it.

What you will not find here is contact details. We record what a site runs, not who runs it. These are accounts worth approaching and a reason to approach them now. They are not a mailing list.

What this is

StackScope watches newly launched websites. Some arrive from public launch directories, and a growing majority are found by our own discovery pipeline watching public internet infrastructure for brand-new sites (see StackScope Discovery). Each one is crawled at launch time for frameworks, hosting, CDN, DNS and email configuration, and the SaaS tools loaded on the page. Sites arriving from a launch channel also get a deeper analysis that adds security posture and quality scoring. The result is a corpus built around one question: what appeared on the web this week, and what did it ship with?

The web-scale directories index everything. We index the newest slice of it, and analyse each site at launch time instead of on a revisit schedule. That is the entire product.

The numbers

These are queried live from the corpus, not marketing copy. They are cached for a few hours and move constantly.

Sites indexed in total	655,103
Available through the API and feeds	583,057
Of those, promoted as indie launches	137,349
Indie launches promoted from discovery	128,589
Added from launch channels, past 7 days	527
Added from discovery, past 7 days	272,730
Active technology fingerprints	14,881
Technology categories	116
With full launch-time analysis (infra, quality, agent signals)	8,948
Launches under liveness tracking	8,955

Sites indexed is every site we have crawled and detected technology on, including the broad discovery stream: local businesses, corporate sites, and the general new web our pipeline finds alongside the launches. The API serves that corpus with two exceptions. No Product Hunt data goes through any paid service: a site that Product Hunt listed is served only where our own discovery pipeline found it independently, and never with Product Hunt's name, tagline or link attached. PeerPush listings are excluded on the same terms while we wait for their agreement. We asked them the day the API opened, because their listings reached us under a non-commercial understanding and we would rather leave them out than assume. If they agree, they come back in; if not, they stay out.

Most of what we index is not a startup launch. Promoted as indie launches is the slice our review classed as an actual launch; the rest are real sites of every other kind. Every row carries an indie flag and the endpoints take an indie filter, so you can take the launches only, the wider web only, or all of it. The two inflow rows are split because almost all of the weekly inflow is our own discovery pipeline finding sites, rather than launches arriving from public directories. Those two rows count what arrived in the window, before review, so they are much larger than the promoted totals above them: most of what discovery finds is a real site but not a launch, and is never promoted.

Launch types

Every launch carries a launch type, and every list surface filters on it:

directory: found on a public launch directory or community, including Hacker News and others. Product Hunt and PeerPush listings are not served through the paid products, for the reasons above.

discovered: found by our own discovery pipeline. These sites usually have no launch-directory listing at all: discovery finds them from public infrastructure signals, without waiting for someone to post them. The discovered stream is first-party data end to end. We found these sites ourselves, and none of it is resold from someone else's listing. It is not filtered down to startup launches: most of it is the ordinary new web.

Sites that owners submit to StackScope privately for a readiness check are not part of the paid dataset at all.

The lookup API

Give it a domain, get the launch and its stack: the launch record, and the technologies detected on its most recent crawl with per-technology confidence and first and last seen dates. Parsed email posture (DMARC, DKIM presence, MTA-STS, DNSSEC) is available for every row. Unknown domains return not-found.

Infrastructure (ASN, registrar, TLS), quality scores and agent-readiness signals come from the deeper launch-time analysis, and only some rows carry it. Sites that arrived from a launch channel are analysed in full; the discovery stream is a lighter crawl that records the stack and DNS but not the rest. The count is in the table above, so you can see how much of the corpus those blocks cover before you buy. Request them and they are returned wherever they exist.

The feed

The pull side: a newest-first feed of sites, filterable by technology, category, country, launch type, indie flag, and a launch-date window. "Every site in this category between these two dates" is one query.

It also includes per-technology launch lists, full-history weekly adoption trends that always carry our methodology annotations (so a detection-coverage change is never mistaken for organic adoption), and CSV export of any list query. The full reference lives in the API docs.

The feed, the per-technology lists and the trends are the browse surfaces, and they start at the Pro plan. Domain lookup, CSV export and Stackdar watches are on every plan, so an Indie plan covers watching your own corner of the market; Pro is the step up to querying the corpus at large.

Without writing any code

Not everything here is an API. These two need no key and no code, and nor does a Stackdar email digest, covered next.

Downloads from your account. Pick a technology, category, country, launch type and date range on the download page, and get a spreadsheet back. It runs the same query as the export endpoint and is metered the same way: one credit, plus every launch in the file counted once against your distinct-launch ceiling. A search that matches nothing is not charged for.

Extended pages on the site. While you are signed in, the public technology and category pages show more than they show a visitor: more launches on each page, every tool in a category instead of the first few, and the full list of technologies that appear alongside the one you are looking at. Bulk retrieval stays in the download and the export endpoint, where it is counted.

Stackdar alerts

Stackdar is the push side: standing watches over newly detected launches. "Tell me when a new launch ships with Supabase", or "alert me on every discovered launch in Germany". Delivery is by HMAC-signed webhook, Slack webhook, or email digest. Alerts fire only on real launch-time detections, never on backfills, so an alert always means a new launch shipped with the technology, not that we newly learned to detect it.

Stackdar sees the same corpus as the API, and nothing in the discovery stream is held back from alerts.

You narrow it at the watch instead: by technology, category, country, launch type, and the same indie flag the endpoints take. This matters for volume. A watch scoped to discovered sites with indie left unset covers the ordinary new web as well as startup launches, which is several times the traffic of the same watch limited to launches. Set indie if you want the launches only.

Email digests go out at an hour you choose, in your own timezone, and stay at that hour through daylight saving. You can take the list as a CSV attachment rather than a long email. Webhooks are near-instant and are the right channel for anything high volume.

What a record means

A record is a launch-time observation. It tells you what a site shipped with on the day it launched, not a guess about what it runs today. Every payload carries observedSince, lastCrawledAt and crawlCount, so you can see how the observation itself was made and how old it is. There is no scheduled recrawl of the back catalogue, so stack-change alerts on existing domains are outside what this data supports. Liveness transitions come from a tiered daily prober. They are launch metadata; do not read them as an uptime signal. Quality scores are exact in per-domain lookups and banded into quintiles in bulk payloads, on the rows that carry the deeper analysis. Aggregate counts in the products use the same hidden, public and duplicate rules as the public site, but they are NOT limited to indie launches the way the public pages are, so a count here is usually larger than the equivalent figure on the site. Add indie=true to match what the public pages show.

Launches we only know about from Product Hunt are not included in any paid product, and PeerPush launches are treated the same way while we wait for their agreement. When our own discovery pipeline has independently found and analysed such a site, that analysis is included, and it carries only data our own crawler obtained. No listing data from either platform appears in any payload: not their listing names, not their taglines, not their listing URLs.

Where we draw the line

We do not serve detection methods, matching rules, or per-detection evidence: a payload tells you what was detected, never how. There is no on-demand scanning of arbitrary domains, no raw DNS records (only parsed posture), and no personal data in anything we serve.

Pricing

Two things are metered, and both are published here. Every data request costs one credit, whether it is a lookup, a feed page or an export; watches and the status endpoint are free. Separately, each distinct launch you touch in a month counts once against a ceiling; looking the same launch up again inside that month is free. Watches are the tier lever. Watching a single technology's new adopters starts around $295 a month elsewhere as of July 2026, and API access starts higher again. Compare that with the grid below.

The two meters behave differently and it is worth knowing which one you are spending. A lookup costs one credit and touches one launch. An export costs one credit regardless of size, but every row it returns counts against your distinct-launch ceiling, so a single large export can spend a whole month of that ceiling at once. Every response carries X-StackScope-Credits-Remaining and X-StackScope-Launches-Remaining so you can see both budgets as you go. Launches you have already touched this billing month are always free to fetch again.

Prices are billed monthly, in the currency shown at checkout: pounds in the UK, dollars elsewhere. StackScope is not VAT registered, so no VAT is added and none appears on your invoice. Credits do not roll over and there are no automatic overage charges: a tier runs out, and we never bill you for more. The every-launch stream is a watch with no technology filter. You name nothing to follow and it delivers every new launch we detect. Only Firehose can create one, and it goes by webhook or Slack, never email. Tens of thousands of sites a day is not something to put in an inbox.

Changing plan. You are not locked to a tier. Moving up applies straight away, with the difference added to your next invoice. Moving down takes effect at the end of the period you have already paid for, so you keep the larger plan until then. Cancelling works the same way. All of it is self-serve from your account. A key's scopes are fixed when it is minted, so after an upgrade mint a new key from your keys page to use the extra endpoints; the old key keeps working for everything it already did.

What you are agreeing to. Every plan is covered by the paid data terms and licence. Two boundaries matter before you subscribe. Your product may show parts of the data alongside analysis or functionality of its own, but it may not let users extract, query or rebuild the corpus, or stand in for StackScope itself. And the data may not be used to train, fine-tune, benchmark or distil a machine-learning model. The licence sets out the rest, including attribution and what a record does and does not claim.

Access

Subscribing takes you to Stripe, which collects your email and card details; we never see the card. You will be asked to accept the paid data terms and licence as part of checkout. Your account and API key are ready as soon as the payment goes through.

If you would rather talk to us first, or you need something the plans above do not cover, write to [email protected] and tell us what you would build with it.

Back to plans and pricing Read the data licence