API reference

/lookup is on every plan, so this is the shape of a first request whichever one you pick. A key comes with a subscription.

You get back the launch, when it shipped, where it was found, and the stack detected on it. A domain we have never crawled returns 200 with {"found": false}, which costs a credit and no distinct launch.

Reading a response

Dates and windows

Casing: JSON is camelCase in both directions (launchType in a body, hasWebhook in a response); query parameters and CSV headers are snake_case (launch_type, observed_since). The split is deliberate, so the same concept changes shape between a URL and a body.

Every timestamp we send is UTC, ISO 8601, with an explicit offset. Every date parameter is read as UTC: a bare 2026-04-01 means midnight UTC that morning, so passing a bare date from a machine in another timezone does not quietly shift the window.

Timestamp windows (since/until, observed_since/observed_until) are inclusive at the lower bound, exclusive at the upper. since=2026-04-01&until=2026-05-01 is the whole of April and no part of May, so consecutive calls where each until becomes the next since tile the corpus exactly once: no row served twice, none skipped.

/tech is the deliberate exception: its from and to name whole days rather than instants, and both ends are inclusive. from=2026-06-01&to=2026-06-30 is all of June, 30 June included.

Paging

count is the number of rows in this response, never a total for the query.

List results sort newest first and break ties on an internal id, so the order is total rather than merely mostly-sorted. Within a fixed window that ordering is stable: repeating the same parameters against the same bounded range returns the same rows in the same order. Leave the upper bound open and new arrivals can land at the top between calls, which is why a polling job should freeze observed_until before it starts.

To walk a result set, prefer cursor over offset on /launches: pass back the nextCursor you were given, unchanged, and stop when a response has none. Offsets re-count from the top on every call, so a row arriving mid-walk shifts everything down and you re-read a row you already had. Treat the cursor as opaque; its contents are not part of the contract.

The cursor records where you got to, and carries a fingerprint of what you asked for, so send the original filters with every page and add the cursor alongside them. A mismatch is refused with 400 cursor_filter_mismatch before either meter is touched, so a dropped filter cannot silently hand you a different population mid-walk.

For a polling job, fix both ends of the window before you start: read up to a boundary you choose (observed_until), page through that frozen range, and make this run's upper bound the next run's observed_since. Rows arriving mid-walk then land in the next run rather than shifting the one in progress.

End that window short of the present. A row is stamped with observedSince when we collect it and becomes visible when its batch commits, a little later. A window ending at "now" can therefore gain rows after you have read it, and those are lost for good: your next run starts at this run's upper bound, and they carry an observedSince below it. Hold the bound back by several minutes; fifteen is a comfortable margin, and the cost is latency rather than lost rows.

What is in the corpus

Rows come from our own crawl of sites found by StackScope Discovery and from public launch directories. Two exclusions are worth knowing before you build on the numbers:

• Product Hunt listings are not sold. A launch we know about only from Product Hunt is not served. Where StackScope Discovery independently found the same site, the row is served as ours, with the platform's name, tagline and listing URL stripped: the host stands in for the name. Product Hunt is excluded because their API terms require it. PeerPush was held out on the same terms until they gave permission on 4 August 2026, and is now served.
• Owner submissions are private. A site added by its own owner through the website is never served, on any plan.

Set against that, indie tells you which rows passed review as launches and which are ordinary sites Discovery picked up.

Versioning

/api/v1 is stable: no breaking field removals or type changes within v1. Additive fields may appear. A breaking change ships as /api/v2.

A key is ss_live_ plus 43 base64url characters (51 total). It is shown once at creation and stored only as a hash: it cannot be recovered, only revoked and re-minted from the keys page in your account. Keys carry scopes; plan and quotas live on your account, so extra keys never multiply the quota.

Error semantics

Introspection. Confirm a key works and see its plan and scopes. Free, so it is safe for health checks and CI.

Looks up a domain and returns its launch record, the stack detected when it was crawled, and any requested enrichment. A full URL is accepted for convenience, but only the host is matched: the path you supply is ignored, and a bare domain also matches launches recorded on a path beneath it. Where several rows share a host, a homepage row wins, then the most recently launched. Subdomains are distinct hosts. A leading www. is folded away, so www.example.com and example.com are the same lookup, but app.example.com is a different site and will not resolve to the apex row, or the other way round. Every call costs one credit. Looking up a launch you have already touched this month costs no further distinct launch, so re-checking a domain you follow is cheap against the ceiling but not against credits. An unknown domain returns 200 {"found": false}.

The public fingerprint catalogue, ranked by distinct launch count.

Launches using a tech, newest first. An unknown, internal, or inactive slug returns 404, so the internal namespace cannot be enumerated.

curl -H "Authorization: Bearer $STACKSCOPE_API_KEY" \
  "https://stackscope.dev/api/v1/tech/nextjs/launches?since=2026-07-01&limit=50"

{
  "slug": "nextjs",
  "count": 1,
  "offset": 0,
  "launches": [
    {
      "shortId": "1j0cal6y",
      "slug": "echo-wander-audio-stories-that-listen-back",
      "name": "Echo Wander - Audio stories that listen back.",
      "tagline": "A romantasy you play with your voice. Authored scenes, AI-generated bridges.",
      "url": "https://echowander.app/",
      "source": "first_party",
      "launchedAt": "2026-08-01T17:35:03+00:00",
      "category": "content",
      "livenessStatus": null,
      "quality": null,
      "launchType": "discovered",
      "indie": false,
      "categoryConfidence": 1,
      "country": null,
      "countryConfidence": null,
      "observedSince": "2026-08-01T17:35:45.781582+00:00"
    }
  ]
}

The pull feed: new launches, filterable, newest first. Poll it on your own schedule, or let Stackdar push instead.

# Freeze the window at the start of the run so rows
# arriving mid-walk cannot shift the pages, and end it
# short of now so the range has settled before you read it.
FROM=2026-07-27T00:00:00Z    # last run's TO
TO=2026-07-28T01:00:00Z      # now minus 15 minutes, NOT now

Q="observed_since=$FROM&observed_until=$TO&country=US&indie=true"

curl -H "Authorization: Bearer $STACKSCOPE_API_KEY" \
  "https://stackscope.dev/api/v1/launches?$Q"

# Every page repeats the SAME filters and adds the
# cursor you were given. Stop when nextCursor is absent.
curl -H "Authorization: Bearer $STACKSCOPE_API_KEY" \
  "https://stackscope.dev/api/v1/launches?$Q&cursor=eyJjdXJzb3IiOiJvcGFxdWUifQ"

# Next run: FROM becomes this run's TO.

{
  "count": 1,
  "offset": 0,
  "nextCursor": "bDoxNzg1NjA1Mzc0MDAwOjg1NjM3NDozMDkzMWI5ZQ",
  "launches": [
    {
      "shortId": "iuvrduuj",
      "slug": "flip-the-city",
      "name": "FLIP the city",
      "tagline": "Unlock hidden stories and follow location-based audio walks.",
      "url": "https://flipthecity.tech/",
      "source": "first_party",
      "launchedAt": "2026-08-01T17:29:34+00:00",
      "category": null,
      "livenessStatus": null,
      "quality": null,
      "launchType": "discovered",
      "indie": true,
      "categoryConfidence": 0.74,
      "country": null,
      "countryConfidence": null,
      "observedSince": "2026-08-01T17:30:09.106321+00:00"
    }
  ]
}

Weekly distinct counts for a technology across the population the lens selects, over the full history available for that lens, plus methodology annotations across the same range. The public chart trims to a 90-day display window; this endpoint does not, so you get the series back to the start of the corpus.

Buckets are weeks starting Monday, dated by the launch date. The first and last buckets are usually partial: the first because the corpus opens on 1 April 2026 and that Monday falls before it, the last because the current week is still filling. Drop both before charting a rate, or the line appears to start low and end in a cliff.

The stack of a set of sites as counts and shares rather than rows: how many of the sites matching your filters carry anything in each kind of technology (payments, analytics, hosting, cms), and which technologies inside each kind, ranked. "Of the sites built with Ghost, what share take payments, and through whom" is one call.

Aggregate only, so it returns no per-launch rows and never consumes the distinct-launch ceiling. Each distinct set of filters counts as one Explore slice against your plan's monthly allowance the first time it is worked out; the same filters asked again inside ten minutes, by API, MCP or the portal, come from cache and count nothing.

Takes the /launches filters by the same names (tech, keywords, category, country, launch_type, indie, since, until, observed_since, observed_until, has_email, has_contact_url, min_country_confidence) and one of its own:

CSV of the feed or a tech's launches. Returns text/csv with a Content-Disposition filename.

curl -H "Authorization: Bearer $STACKSCOPE_API_KEY" \
  "https://stackscope.dev/api/v1/export?tech=nextjs&since=2026-07-01" -o launches.csv

short_id, slug, name, tagline, url,
source, launch_type, indie, launched_at, observed_since,
category, category_confidence,
country, country_confidence, liveness_status

# with the contacts scope, inserted after url:
contact_email, contact_url, contact_checked_at

# with include=quality, appended:
security_band, performance_band, ai_built_band,
stackscope_band, readiness_band, green_hosted

Every watch on your account, newest first. The signing secret is never echoed back, and neither is the full webhook URL: hasWebhook says whether one is set and webhookHost names the host, which is enough to tell watches apart without exposing a path or query that may carry a token.

Watches are immutable. There is no update: to change a filter, a channel or a schedule, delete the watch and create a new one. Creating a new webhook watch mints a new signing secret, so plan for the rotation. Nothing stops you creating two watches with identical filters, and both will fire.

consecutiveFailures is the run of failed deliveries. It resets to zero on any 2xx, and a watch that reaches twenty is switched off, which shows as isActive: false.

Creates one watch. Your plan caps how many you may hold and how many technologies each may name; over either, the call returns 429 watch_limit_reached or a 400 saying which bound you crossed.

Deletes one of your watches and stops it firing immediately. Its filters and signing secret go with it. A watch that is not yours, or does not exist, returns 404: the two are deliberately indistinguishable.

Two meters

Plans

Keywords per watch follow the same number as techs per watch, on a separate allowance, so a technology and a keyword fit together on every plan.

Precise quality scores (0 to 100) come only from the metered /lookup; bulk payloads return quintile bands instead, 1 lowest to 5 highest.

Prices for each plan, and what the data covers, are on the Data and API page.

What fires

A new_launch event fires when a launch first becomes eligible: it is public and its first successful crawl carries a live detection. An alert can trail the crawl by up to a few hours while enrichment finishes, and a discovered row becomes eligible only once review keeps it. Re-detections of old crawls never fire, so an alert always means "a new launch shipped with X", not "detection coverage improved". Matching is AND across filter dimensions; an empty dimension is a wildcard, and a tech filter matches any of the watched slugs. A keyword filter matches any of its words, as whole words in the launch's name, tagline, page title, first heading or meta description; the delivery then says which word matched, as matchedKeywords on the webhook payload, a matched: suffix on the Slack line and a Matched: line in the digest.

Channels

Webhook and Slack URLs must be HTTPS and resolve to a public address; the exact rules are under webhookUrl.

Delivery semantics

There is no scheduled recrawl of the back catalogue, so this data does not support stack-change alerts on existing domains.

Sites under liveness tracking are checked daily. Those changes are launch metadata, not an uptime signal. Quality scores are exact in per-domain lookups and grouped into five bands in bulk results, on the rows that carry the deeper analysis.

Aggregate counts follow the same rules as the public site for hidden and duplicate records, but they are not limited to indie launches. A count here will therefore usually be larger than the equivalent figure on the public site. Add indie=true to match the public pages.

Launch types

Every launch carries a launch type, and you can filter every list by it:

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