Technographic data API
Query the technology stack of 29.9M active domains. 29 REST endpoints covering detection, company data, category share, and adoption, churn and switch signals — starting at 100 free credits a month.
What a technographic data API returns
It answers over HTTP which software a company runs, the way a firmographic API answers how big it is and where it sits. Send a domain and get its stack back; send a technology and get the companies running it.
- TechnologyChecker.io's technographic data API covers 40,000+ technologies across 50M+ domains, 29.9M of them active as of August 2026, and that active set is the denominator behind every market-share figure the API returns.
- A single GET /v1/domain/{domain} call costs one credit and returns every technology currently detected on that domain plus the ones it has moved off, each stamped with a first-seen and a last-seen date.
- Detection is multi-signal rather than markup-only, reading HTTP response headers, the rendered DOM after JavaScript executes, JavaScript globals, asset fingerprints, DNS records, TLS certificates and certificate transparency logs.
- The signal endpoints return technology adoption, churn, competitive switches and category gaps over a 30-day default window, and every churn or adoption event carries a 0-100 confidence score rather than being asserted flat.
- Counts are domains rather than accounts: a detection means TechnologyChecker.io observed a technology's signature on a publicly reachable domain, so a domain count is an upper bound on customers and not a substitute for one.
- The free plan is 100 credits a month with no card, and rate limits are enforced per key at 60 requests a minute on Free, 300 on Pro and Scale, and 1,000 on Enterprise.
8 groups, 29 endpoints
One base URL, one bearer token, JSON in and JSON out. Most calls cost a single credit; the account endpoints and the whole of the alerts surface cost nothing at all.
https://api.technologychecker.io
- Domain technologiesWhat is this website running?3 endpoints1 credit per request
- Technology dataResolve names to a stable catalog.2 endpoints1 credit per request
- Market intelligenceAdoption counts and category share.3 endpoints1 credit per request
- Company dataFirmographics on the domains you matched.4 endpoints1 credit · batch 1 per domain
- Technology signalsWho just adopted, dropped or switched.6 endpoints1 credit · export 1 per row
- AlertsSubscribe to a signal instead of polling it.7 endpointsFree, no credits consumed
- Live detectionScan a URL that isn't in the corpus yet.2 endpoints5 credits per request
- AccountWatch your own consumption.2 endpointsFree, no credits consumed
Start
querying
A real request, the real response it returns, and every field you get back. No tab-hopping to the docs to find out what arrives.
Get a company's tech stack
1 creditOne call by domain returns everything currently detected on it, plus what it used to run. The first-seen and last-seen dates on every entry are what let you tell a live stack from its history.
GET /v1/domain/{domain}
curl -H "Authorization: Bearer YOUR_API_KEY" \
https://api.technologychecker.io/v1/domain/shopify.comimport requests
response = requests.get(
"https://api.technologychecker.io/v1/domain/shopify.com",
headers={"Authorization": "Bearer YOUR_API_KEY"},
)
print(response.json())const response = await fetch(
"https://api.technologychecker.io/v1/domain/shopify.com",
{ headers: { Authorization: "Bearer YOUR_API_KEY" } },
)
const data = await response.json(){
"success": true,
"data": {
"domain": "shopify.com",
"active_technologies": [
{
"id": 2,
"name": "Cloudflare",
"category": "CDN",
"first_seen": "2020-05-08 00:00:00",
"last_seen": "2026-01-08 00:00:00",
"subdomain": "SHOPIFY.COM"
},
{
"id": 4,
"name": "SSL by Default",
"category": "SSL/TLS Certificates",
"first_seen": "2015-09-08 00:00:00",
"last_seen": "2026-01-08 00:00:00",
"subdomain": "SHOPIFY.COM"
}
],
"historical_technologies": [ ... ]
}
}What you get
- id
- Stable technology ID — resolve names to this once, then key on it
- name
- Technology name, e.g. Cloudflare
- category
- What kind of tool it is, e.g. CDN or Ecommerce Platforms
- first_seen
- When we first detected it on this host
- last_seen
- Most recent detection — how you judge whether an answer is stale
- subdomain
- The host the detection belongs to, so a docs subdomain is not read as the apex
Split into active_technologies and historical_technologies, so a stack and the things a company has moved off arrive in the same response.
Find the companies using a technology
1 creditThe prospecting call. Start from a competitor or a complementary tool and filter server-side by country, industry and headcount, so you are not paying to enrich rows you would throw away.
GET /v1/technology/{id}/companies
curl -G -H "Authorization: Bearer YOUR_API_KEY" \
https://api.technologychecker.io/v1/technology/23/companies \
--data-urlencode "country=turkey" \
--data-urlencode "industry=software development" \
--data-urlencode "limit=50"{
"success": true,
"data": {
"technology": {
"id": 23,
"name": "WordPress",
"category": "CMS Platforms"
},
"companies": [
{
"domain": "example.com",
"company_name": "Example Corp",
"linkedin_url": "https://linkedin.com/company/example",
"industry": "Software Development",
"country": "Turkey",
"city": "Istanbul",
"founded": 2015,
"employees": "51-200",
"company_type": "Privately Held",
"associated_members": 150
}
],
"total": 423,
"limit": 50,
"offset": 0
}
}What you get
- domain
- The company's domain, which is also the key for every other endpoint
- company_name
- Registered company name
- linkedin_url
- The organisation's own LinkedIn page
- industry
- Industry label, filterable by name or LinkedIn code
- country · city · state
- Headquarters location, each filterable
- founded
- Founding year, with founded_min and founded_max as filters
- employees
- Headcount band, e.g. 51-200
- company_type
- Public, privately held, and so on
- associated_members
- LinkedIn member count, which is also the sort order
total is the full match count, so you can page with limit and offset rather than guessing how deep the list goes. Counts are domains: one company can own several.
Track adoption and churn
1 creditWho started using a technology in the last 30 days, and who dropped it. This is the call that turns a static stack into a buying window, and every event carries a confidence score rather than being asserted flat.
GET /v1/signals/{churn|adoption}
curl -G -H "Authorization: Bearer YOUR_API_KEY" \
https://api.technologychecker.io/v1/signals/churn \
--data-urlencode "technology=Intercom" \
--data-urlencode "window=30" \
--data-urlencode "limit=100"{
"success": true,
"data": {
"signal": { "type": "churn", "verb": "dropped" },
"scope": "technology",
"technology": {
"id": 52,
"name": "Intercom",
"category": "Live Chat"
},
"window_days": 30,
"total_sites": 2847,
"domains": [
{
"domain": "example.com",
"detection_url": "https://example.com",
"technology_name": "Intercom",
"event_at": "2026-08-14 14:10:33",
"last_detected": "2026-07-18 07:39:59",
"detection_rate": 0.86,
"detection_count": 6,
"confidence": { "score": 92, "label": "high" }
}
],
"count": 1
}
}What you get
- event_at
- When the change was observed — the start of your outreach window
- last_detected
- The last time we saw the technology before it went
- detection_url
- The exact host the event happened on, not just the apex domain
- confidence
- A 0-100 score and a high, medium or low label on this single event
- detection_count
- How many separate crawls saw the technology, so you can judge persistence
- detection_rate
- Share of scans that saw it — a flaky signal scores lower
- total_sites
- Corpus-wide count of sites with this event in the window, not just the rows returned
Scope by technology or by a whole category, and swap churn for adoption on the same call. Absence in one crawl is not proof of removal, which is exactly what the confidence score exists to grade — so filter on it rather than treating every row as certain.
See who switched to a competitor
1 creditA switch joins two changes on one host: a technology dropped and a competing one in the same category adopted. It answers the two questions a sales team pays for — who left a rival for you, and who is leaving you — and the flow block ranks the destinations across the whole corpus, not just the rows returned.
GET /v1/signals/switch
curl -G -H "Authorization: Bearer YOUR_API_KEY" \
https://api.technologychecker.io/v1/signals/switch \
--data-urlencode "technology=Shopify" \
--data-urlencode "direction=from" \
--data-urlencode "window=90" \
--data-urlencode "country=united states"{
"success": true,
"data": {
"signal": { "type": "switch", "verb": "switched" },
"scope": { "kind": "technology", "direction": "from" },
"technology": {
"id": 2184,
"name": "Shopify",
"category": "Ecommerce Platforms"
},
"window_days": 90,
"flow": [
{ "to_id": 402, "to_name": "WooCommerce", "sites": 69 },
{ "to_id": 2002, "to_name": "Magento", "sites": 20 }
],
"switches": [
{
"domain": "example.com",
"from": { "id": 2184, "name": "Shopify" },
"to": { "id": 402, "name": "WooCommerce" },
"category": "Ecommerce Platforms",
"churned_at": "2026-08-20 14:02:11",
"adopted_at": "2026-08-20 14:02:11",
"gap_days": 0,
"confidence": "medium",
"company": {
"name": "Example Corp",
"industry": "Retail",
"employees": "11-50",
"country": "united states"
}
}
],
"count": 1
}
}What you get
- from · to
- The technology that went and the competing one that replaced it
- gap_days
- Days between the two events — a real in-place swap shows nought or one
- churned_at · adopted_at
- When each half of the switch was observed
- confidence
- High, medium or low, graded from the gap and how reliably we saw the old technology
- flow
- Where everyone went: distinct sites per destination technology, corpus-wide
- company
- The LinkedIn company card, attached when the same firmographic filters are applied
Competitors are defined by shared category, so a web server moving behind a CDN can never register as a switch. Direction flips the question: from is who left, to is who arrived.
Signals,
not snapshots
Four endpoints that turn a stack into a change feed, and the guards that decide how much of it you should believe.
Everything above answers what a domain runs today. These answer what changed. A signal is a transition in the crawl's own record of state — a technology that was there and is now gone, or was absent and is now present — scoped to one technology or to every technology in a category, over a window you choose up to a year.
- AdoptionWho started running this technology?
GET /v1/signals/adoptionOne technology, or every technology in a category - ChurnWho dropped it?
GET /v1/signals/churnOne technology, or every technology in a category - Competitive switchWho replaced it with a rival, and which one?
GET /v1/signals/switchLosses from a technology, wins to it, or a whole category - Category whitespaceWho runs the anchor but nothing at all in a category?
GET /v1/signals/whitespaceAn anchor technology or category, plus the category they lack
The same firmographic filters as the company endpoints apply inside the query rather than after it, so filtering to, say, United States companies of 51 to 200 people shrinks both the rows returned and the corpus-wide count. Roughly a quarter to a third of domains have a matched company record, and the response says so rather than quietly returning a smaller list.
How far to trust a signal
A technology missing from one crawl is not proof it was removed. That single fact governs the design of everything below, and it is why a signal arrives graded rather than asserted.
- Every event carries a score, not an assertion
- Each churn and adoption row returns a 0-100 confidence score and a high, medium or low label. It combines three things: how stable the detection method is, how many separate crawls saw the technology, and how consistently they saw it. Filter on it rather than treating every row as certain.
- A single sighting is never high confidence
- A technology observed on only one prior scan is a snapshot, not corroboration, so a churn built on it is capped at low. The removal presupposes the presence, and a presence caught once is itself unconfirmed.
- A whole stack dropping at once is a failed crawl
- When three or more technologies on the same host go absent in the same second and nothing is adopted alongside them, that is a blocked or empty render, not a replatform. Those events are capped at low. A genuine replatform adds its replacements in the same scan, so it is spared.
- A technology we have already lost and found is a flapper
- If the same technology on the same host has gone absent and come back in the last 60 days, a new absence is almost certainly another miss, so it is capped at low. On a back-test of cadence-scanned hosts, churns with exactly one prior recovery came back 97.4% of the time.
- Adoption excludes first-time-crawled domains by default
- A domain we have never seen before stamps its entire stack as new at once, which would read as mass adoption. Those rows are gated out unless you ask for them, so an adoption means a technology appeared on a host we already knew.
- You can force the question
- POST /v1/signals/churn/validate re-detects a candidate right now, in a real browser with consent banners clicked, and returns one of four verdicts: confirmed, false positive, masked by a newly added CDN, or inconclusive. An inconclusive result is our failure and is not charged.
Subscribe instead of polling
Every signal you can query, you can subscribe to. Save the query with a webhook URL and only the new events arrive — no cursor to keep, no re-scanning a window you have already read.
- What an alert is
- A saved signals query, a watermark, and an HTTPS webhook. The scope and filter vocabulary is the one you already used on the signal endpoint, so a tested query becomes a subscription unchanged.
- What you can subscribe to
- Adoption, churn, switch, whitespace entrants, and any stack change on a named list of your own accounts.
- Delivery
- A sweep runs hourly; each alert fires at most once a day by default, batching the day's events into one delivery, or hourly if you prefer the drip. Quiet windows send nothing at all.
- Signing
- Every request carries an HMAC-SHA256 signature over the timestamp and raw body, using the secret returned when you created the alert.
- Redelivery
- Delivery is at least once: a failed or timed-out endpoint holds the watermark and the next sweep repeats the window. Dedupe on the delivery ID header.
- Cost and caps
- Alerts, sweeps and deliveries consume no credits. Free keeps 1 alert and 100 watched domains; Pro 5, Scale 15 and Enterprise 50, each with 1,000 watched domains.
The signal and alert endpoints are newer than the published API reference and are not in it yet. What they return is on this page; if you need the full parameter list before it lands there, ask us.
Every
endpoint
A summary, not the reference. Request and response schemas, query parameters and error codes for the detection, technology, market and company endpoints live in the API documentation.
Domain technologies
| Method | Path | Returns | Credits |
|---|---|---|---|
| GET | /v1/domain/{domain} | Active and historical technologies for one domain, each with first-seen and last-seen dates | 1 |
| GET | /v1/domain/{domain}/history | Full technology history for a domain, with active and removed status per entry | 1 |
| GET | /v1/technology/name/{name}/domains | Top domains running a named technology | 1 |
Technology data
| Method | Path | Returns | Credits |
|---|---|---|---|
| GET | /v1/technology/{id}/info | Extended detail for one technology: description, website, icon, category and group | 1 |
| GET | /v1/technology/name/{name} | Exact, case-insensitive name lookup that resolves to a technology ID | 1 |
Market intelligence
| Method | Path | Returns | Credits |
|---|---|---|---|
| GET | /v1/technology/{id}/stats | Active and total domain counts for one technology | 1 |
| GET | /v1/technology/{id}/history | Monthly usage series, up to 20 years deep | 1 |
| GET | /v1/category/{id}/market-share | Ranked technologies in a category with each one's share of that category | 1 |
Company data
| Method | Path | Returns | Credits |
|---|---|---|---|
| GET | /v1/technology/{id}/companies | Companies running a technology, filterable by country, industry and headcount | 1 |
| GET | /v1/company/{domain} | Firmographic record for one domain | 1 |
| GET | /v1/companies | Company search across the firmographic index | 1 |
| POST | /v1/companies/batch | Firmographic records for many domains in one call | 1 per domain |
Technology signals
| Method | Path | Returns | Credits |
|---|---|---|---|
| GET | /v1/signals | The signal types available to query | 0 |
| GET | /v1/signals/{churn|adoption} | Domains that dropped or newly started running a technology in the window, each with a confidence score | 1 |
| GET | /v1/signals/switch | Domains that replaced one technology with a competing one, with the destination distribution | 1 |
| GET | /v1/signals/whitespace | Domains running an anchor technology but nothing at all in a target category | 1 |
| GET | /v1/signals/{type}/export | The same churn or adoption query as CSV, up to 10,000 rows, company columns included | 1 per row |
| POST | /v1/signals/churn/validate | A re-detection verdict for a churn candidate: confirmed, false positive, masked or inconclusive | 2 or 5 |
Alerts
| Method | Path | Returns | Credits |
|---|---|---|---|
| GET | /v1/alerts | Your alerts, with status and last fired time | 0 |
| POST | /v1/alerts | A new subscription, plus the signing secret for its webhook | 0 |
| GET | /v1/alerts/{id} | One alert, including its webhook secret | 0 |
| PATCH | /v1/alerts/{id} | Updated name, status, filters, webhook URL or delivery frequency | 0 |
| DELETE | /v1/alerts/{id} | Deletion, cascading to its deliveries | 0 |
| POST | /v1/alerts/{id}/test | A synthetic payload through the real delivery path, for verifying your endpoint | 0 |
| GET | /v1/alerts/{id}/deliveries | The delivery log, optionally with the delivered events embedded | 0 |
Live detection
| Method | Path | Returns | Credits |
|---|---|---|---|
| POST | /v1/technology-lookup-live | Detection run against the live page at request time, in browser or fetch mode | 5 |
| GET | /v1/technology-lookup-live | The same live detection as a query-string call, for testing from a browser | 5 |
Account
| Method | Path | Returns | Credits |
|---|---|---|---|
| GET | /v1/credits | Credit balance, limit and next reset date | 0 |
| GET | /v1/usage | Usage statistics, filterable by date range | 0 |
No key required
GET /free/logo/{domain}Company logo as raw image bytes at 16, 32, 64 or 128 pixels. Drop it straight into an img tag; it is cached at the edge for seven days.
GET /free/company/{domain}Public company profile for a domain, with bulk and fuzzy-search variants alongside it.
- Both share one global bucket of 60 requests a minute across every caller, so they suit embedding rather than bulk work.
Stored
or live
The one architectural decision every integration makes, and the one that decides your credit burn.
Reach for the stored lookup by default. It answers from the pre-crawled corpus for a single credit and carries a 24-hour cache header, so an integration that honours caching spends a fraction of what one that does not will. Live detection is the fallback for a domain the corpus has never seen, or for the rare case where an answer that is current to the second is worth five credits and a browser render.
| Stored lookup | Live detection | |
|---|---|---|
| Endpoint | GET /v1/domain/{domain} | POST /v1/technology-lookup-live |
| Credits | 1 | 5 |
| Answers from | The pre-crawled corpus | A browser render at request time |
| Coverage | 29.9M active domains | Any reachable URL |
| Freshness | As of that domain's last crawl | Current, to the second |
| Cached | 24 hours at the edge | Never cached |
| Reach for it when | You are enriching a list | The domain returned nothing stored |
Credits
and limits
Every plan includes full API access. See pricing for what each one adds beyond the API itself.
| Plan | Price | Credits | Best for |
|---|---|---|---|
| Free | $0 forever | 100 | Evaluating the API and building a proof of concept |
| Pro | $89 per month | 10,000 | A production integration enriching a steady flow of domains |
| Scale | $249 per month | 50,000 | Bulk enrichment runs and analytics over large domain sets |
| Enterprise | Custom talk to us | 500,000 | Custom volume, higher throughput and dedicated support |
Rate limits
Enforced per key on a rolling 60-second window. Going over returns HTTP 429 with a Retry-After header, and a rate-limited request is never charged credits.
Credit costs
Credits reset monthly on your billing date and do not roll over. The account endpoints are free, so you can poll your own balance without spending any of it.
| Operation | Credits |
|---|---|
| Domain lookup, technology lookup, market share, company lookup | 1 |
| Signal query: adoption, churn, switch or whitespace | 1 |
| Batch company lookup | 1 per domain |
| Signal CSV export | 1 per row |
| Churn validation, by fetch or by browser | 2 or 5 |
| Live technology detection | 5 |
| Alerts: creating, sweeping and delivering | Free |
| Full technology catalog export | Free |
| Credit balance and usage statistics | Free |
Start on the free plan for 100 credits a month, no card required.
What the
data is
Where the records come from, and what a detection does and does not tell you.
The corpus is 50M+ total domains, of which 29.9M are active and growing, across 40,000+ tracked technologies. That active set is the denominator behind every usage and market-share figure the API returns.
Detection is multi-signal rather than markup-deep: HTTP response headers, the rendered DOM after JavaScript executes, JavaScript globals, asset fingerprints, DNS records, TLS certificates and certificate transparency logs. The infrastructure layers are what surface backend tooling and standalone platforms that leave no trace in browser-visible source. Full detail is on our methodology page.
The full corpus is re-crawled on a monthly sweep, with high-priority domains refreshed far more often. Every record carries first-seen and last-seen dates, so you can judge how old an answer is instead of assuming.
A detection is not a customer
A detection means the technology's signature was observed on a publicly reachable domain. That domain may be on a free tier, a trial, an agency account, or running the technology as a bundled module inside another platform. Counts are domains, and one company can own many, so treat a domain count as an upper bound on customers rather than a substitute for one.
Company records are entity-level throughout: industry, headcount, location, founding year and the organisation's own LinkedIn page. No consumer personal data passes through these endpoints. See the trust center for how that data is handled, and data removal if you need a domain taken out of the index.
Four
common
flows
Each one names the calls it makes, in order, so you can price it before you write it.
Build a prospect list from a technology
Start from a competitor or a complementary tool and finish with an enriched, filtered list of companies you can hand to sales.
Resolve the technology to an ID
Names are messy and vendors rebrand. Resolve once and store the ID, then everything downstream is stable.
GET /v1/technology/name/klaviyo
Pull the companies running it
Filter server-side by country, industry and headcount so you are not paying to enrich rows you will discard.
GET /v1/technology/{id}/companies?country=US&employees=51-200
Enrich the domains you kept
One batch call attaches firmographics to the whole list. Billing is per domain, so the filtering step above is what controls the cost.
POST /v1/companies/batch
Enrich a CRM you already have
Attach a stack to every account record, then keep it current without re-scanning the whole book.
Look up each account's domain
One call returns the active stack plus first-seen and last-seen dates for every entry, which is what makes trend logic possible later.
GET /v1/domain/{domain}
Cache the answer for a day
Stacks do not change by the minute, and responses carry a 24-hour cache header. Honouring it is the single biggest lever on your credit burn.
Fall back to live only on a miss
If a domain returns nothing stored, scan it live. Costing five credits, this is a fallback, not a default.
POST /v1/technology-lookup-live
Work a competitor's churn
Turn a rival's losses into a worked queue: find the accounts that dropped them, keep only the ones worth a call, confirm the ones you are about to name in an email, then stop polling and let it push.
Pull the churn, filtered where it is cheap to filter
Firmographic filters apply inside the query, so the row count and the corpus-wide headline both shrink to companies that fit. Filtering here rather than after the fact is what keeps the list short enough to work.
GET /v1/signals/churn?technology=Intercom&country=united states&employees=51-200
Read the confidence before the domain
Each event carries a 0-100 score and a label. Low is not noise you must discard, but it is the row where the technology may still be on the site, so it does not belong at the top of a rep's queue.
Confirm the ones you are going to name
Before an email says we noticed you moved off, re-detect it. The verdict comes back confirmed, false positive, masked by a newly added CDN, or inconclusive — and an inconclusive result is our failure, so it is not charged.
POST /v1/signals/churn/validate
Stop polling
Once the query is right, save it as an alert with a webhook and only new events arrive. Delivery is at least once, so dedupe on the delivery ID header rather than assuming each event lands exactly once.
POST /v1/alerts
Size a market
Answer how big a category is, who leads it, and which way the line is moving.
Pull the category's share table
Ranked technologies with each one's share of that category, pre-aggregated so it returns quickly enough to sit behind a dashboard.
GET /v1/category/{id}/market-share
Add the time series
Monthly adoption for the technologies you care about turns a snapshot into a direction.
GET /v1/technology/{id}/history
Read the counts as domains
Every figure counts domains, not accounts. One company can run many domains, so a domain count is an upper bound on customers, never a substitute for one.
Docs and
tooling
The API reference carries request and response schemas, every query parameter, error codes and retry guidance, with examples in cURL, Python and JavaScript. You can also test any endpoint from the playground inside the dashboard, where your key is filled in for you.
If you build with an AI coding assistant, a hosted Model Context Protocol server lets it search these docs directly rather than guessing from web results.
https://technologychecker.io/docs/mcp
Frequently
asked questions.
What is a technographic data API?
A technographic data API answers, over HTTP, which software a company runs — the way a firmographic API answers how big it is and where. You send a domain and get back its technology stack, or you send a technology and get back the companies running it. The TechnologyChecker.io technographic data API covers 40,000+ technologies across 50M+ domains, 29.9M of them active as of August 2026, and adds change endpoints for adoption, churn and competitive switches on top of the current-state lookup.
What is technographic data?
Technographic data describes the software a company runs, the way firmographic data describes its size, industry and location. A technographic record answers which analytics tool, payment processor, CMS or CRM sits on a given domain, when it first appeared and whether it is still there. Sales and go-to-market teams use it to find companies that already run a complementary or competing product.
How do I get an API key?
Sign up at app.technologychecker.io, then open Settings and Developers to create a key. The Free plan includes 100 credits a month and needs no credit card. Keys are passed as a bearer token in the Authorization header.
How much does the API cost?
The Free plan gives 100 credits a month. Pro is $89 a month for 10,000 credits, Scale is $249 a month for 50,000, and Enterprise is custom. Most endpoints cost one credit, live detection costs five, batch company lookups cost one per domain, and the account endpoints are free.
What are the rate limits?
Limits are enforced per API key on a rolling 60-second window: 60 requests a minute on Free, 300 on Pro and Scale, and 1,000 on Enterprise. Exceeding a limit returns HTTP 429 with a Retry-After header, and a rate-limited request is never charged credits.
How many domains and technologies does the API cover?
The corpus is 50M+ total domains, of which 29.9M are active and growing, across 40,000+ tracked technologies. The active set is the denominator behind any usage or market-share figure the API returns.
Can the API tell me when a company adopts or drops a technology?
Yes, that is what the signal endpoints do. GET /v1/signals/adoption and GET /v1/signals/churn return the domains that started or stopped running a technology inside a window, GET /v1/signals/switch returns the ones that replaced it with a competitor and names the replacement, and GET /v1/signals/whitespace returns the ones running an anchor technology but nothing at all in a category you choose. Each costs one credit. You can also save any of those queries as an alert with a webhook URL, and a sweep will push only the new events to you, HMAC-signed and free of credits.
How accurate are the adoption and churn signals?
A technology missing from one crawl is not proof it was removed, so every churn and adoption event returns a 0-100 confidence score and a high, medium or low label, built from how stable the detection method is, how many separate crawls saw the technology, and how consistently they saw it. Several patterns are capped at low automatically: a churn built on a single prior sighting, three or more technologies vanishing from one host in the same second with nothing adopted alongside them, and a technology that has already gone missing and come back on that host in the last 60 days. When you need certainty on a specific case, POST /v1/signals/churn/validate re-detects it in a real browser and returns confirmed, false positive, masked by a newly added CDN, or inconclusive.
Are there separate rate limits for the signal endpoints?
Yes, and they are tighter than the rest of the API because each signal query scans a large transition table. Every endpoint under /v1/signals carries an additional per-key limit of 10 requests a minute on Free, 30 on Pro and Scale, and 60 on Enterprise, on top of the general plan limit. The free endpoint that lists the available signal types is exempt. Going over returns HTTP 429 and is never charged credits.
Does a detection mean the company is a paying customer?
No. A detection means the technology's signature was observed on a publicly reachable domain. That domain might be on a free tier, a trial, an agency account, or running the technology as a bundled module inside another platform. Counts are domains, and one company can own many, so treat a domain count as an upper bound rather than a customer number.
Should I use the stored lookup or live detection?
Use the stored domain lookup by default: it costs one credit, answers from the pre-crawled corpus and is cached for 24 hours. Use live detection when the stored lookup returns nothing for a domain, or when an answer that is current to the second matters more than latency and cost. Live detection renders the page in a real browser and costs five credits.
Is there anything I can call without an API key?
Yes. The company logo and company lookup endpoints under the /free namespace need no authentication and consume no credits. They share one global bucket of 60 requests a minute across all callers, so they suit embedding and light use rather than bulk work.
Which languages and SDKs are supported?
Any language with an HTTP client. It is a standard REST API returning JSON, and there is no SDK to install. The documentation carries examples in cURL, Python and JavaScript. A hosted MCP server also lets AI coding tools query the documentation directly.
How fresh is the data?
The full corpus is re-crawled on a monthly sweep, with high-priority domains refreshed far more often. Every stored record carries first-seen and last-seen dates, so you can judge the age of an answer rather than assume it. When freshness matters more than cost, live detection bypasses the corpus entirely.
Start with 100 free credits.
Create a key in the dashboard and make your first call in under a minute. No card required.
Get Started