A technographic data providers API is a programmatic interface that returns the technologies a company is detected or inferred to use, usually looked up by domain or searched by technology. The part that decides whether it is useful is not the endpoint but the record it returns: what evidence produced the detection, which dates come with it, what its "confidence" field actually measures, and what an empty result means. Those four things differ between providers, so a stored technology should carry its own evidence and date, and a seller should be allowed to say only what that evidence supports.
Technographic Data Providers API: The Short Answer
- Compare the record, not the endpoint list. Every provider below returns a technology name and a category. They differ in how the technology was detected, which first and last dates come with it, and whether a score is present.
- "Confidence" is not one measure. BuiltWith computes it from fixed rules about detection dates and domain type. TheirStack derives a low, medium or high rating from job-posting mentions. Cognism's Enrich API returns a match score for the record it matched. None of these is a probability that the account uses the product.
- An empty result is not a negative. TheirStack's documentation states that a technology not mentioned in postings is not a technology that is absent. The same logic applies to any detection method.
- Store one passport per field. The Field Passport below keeps evidence type, dates, the meaning of the score and the permitted use with every technology.
- Say only what the rung allows. The Stack Claim Ladder turns a stored record into one of three message forms: a dated detection, an inference, or a buyer-confirmed fact.
What a Technology Record Proves, Provider by Provider
One rubric for every row: what evidence the provider says produced the record, what dates it returns, what its score means, and what an empty result means. Cells say "Not stated" where the documentation read does not say.
| Provider (source type) | Evidence behind a record | Dates returned | Score field and what it measures | Empty result and limits |
|---|---|---|---|---|
| BuiltWith Domain API v26 (API docs) | Website technologies, current and historical | First and last detected per technology; first and last indexed per path | confidence from 0 to 1. Starts at 1; minus 0.25 when first and last detected dates are equal; minus 0.5 on an actively parked domain; set to 0.5 for operations-tagged records |
Lookup is by root domain, one credit per domain, up to 16 domains per call. Earlier API versions omit the score |
| Wappalyzer lookup API (API docs) | Website scan, cached from its database or run live | confirmedAt per technology in the sample response; max_age defaults to 2 months of verification |
No numeric field in the sample response. denoise defaults to true and excludes low-confidence results |
A new site may return no technologies while a crawl runs, which the docs say can take up to 15 minutes |
| TheirStack technographics API (docs) | Mentions of technologies in job postings (title, description, URL) | First and last date found; number of jobs mentioning the technology, with links | Low, medium or high from mention count, relative frequency in the category, where the mention appears and how recent it is | "A technology that is not mentioned is not a technology that is absent." Coverage inherits job-data biases |
| HG Insights API v2 (data guide) | Install records per product | product_first_verified_date and product_last_verified_date |
An intensity integer and location_count per install; no confidence field in the install record |
Fields depend on subscription plan. Detection method not stated in the guide |
| TechnologyChecker API (API page) | Multi-signal detection: response headers, rendered page, JavaScript globals, asset fingerprints, DNS, TLS records | First-seen and last-seen date per technology | A 0 to 100 confidence on adoption and churn events | Counts are domains, not accounts. |
| PredictLeads technology detections (product page) | Detections gathered from company websites | First seen and last seen | Not stated | Delivered by API, flat files, webhooks and MCP |
| ZoomInfo company enrichment API (product guide) | Websites, job postings, partnership announcements and data partnerships | Not stated | Not stated | Technologies come back as one of several endpoints keyed to a company ID |
| Cognism Enrich API (blog) | Not stated for technology fields | Not stated | matchScore for the best record match, plus field-availability flags |
The score describes the match of the company record, not the technology |
| Demandbase (product page) | Not stated | Not stated | Not stated | The page states a regular refresh without an interval |
| 6sense (API overview) | Not stated | Not stated | Not stated | The overview lists identification, lead scoring and firmographic APIs and says most documentation has moved to the API portal; confirm technographic access there |
| Clay (BuiltWith integration docs) | Passes through BuiltWith, with a Clay-managed account or your own key | As returned by BuiltWith | As returned by BuiltWith | Costs 2 credits per cell on the Clay-managed account |
Fact: the same label, "confidence", appears in the BuiltWith, TheirStack and TechnologyChecker rows and measures a different thing in each. Inference: a team that compares scores across providers is comparing three methods, not three estimates of one quantity. Opinion: treat any score as a note about how the record was produced and ask each provider what produced it.
What the Dates Prove
A first-detected date shows when a provider first saw a trace. A last-detected or last-verified date shows when it last did. Neither date proves that the account bought or still runs the product today. BuiltWith's own scoring documentation treats a record whose first and last detected dates are identical as weaker, which is a provider acknowledging that a single sighting is thin evidence. For job-based evidence, a last-found date means the last posting that mentioned the technology, not the date a team stopped using it.
The Field Passport
The Field Passport is one row stored with every technology you keep. It travels with the value into the CRM or warehouse, so the next person sees what the field is worth.
| Passport field | What it holds | Why it is there |
|---|---|---|
| Account key | Domain or company ID used for the lookup | A technology record about a domain is not automatically about the company |
| Technology and category | The provider's name and category | Needed for matching rules |
| Evidence type | Website scan, job-posting inference, install record, or buyer statement | Decides which message form is allowed |
| First and last date | The provider's two dates, copied unchanged | Feeds the recency rule and shows when a record ended |
| Score and meaning | The raw score plus a note on what produced it | Prevents comparing unlike scores |
| Pulled on | The date your system called the API | Separates provider freshness from your own |
| Verification | None, seller-checked, or buyer-confirmed | Moves the record up the ladder |
| Allowed use | Segment only, seller research, or stated in outreach | The action the record is cleared for |
The Stack Claim Ladder
The Stack Claim Ladder has three rungs. A record starts on the lowest rung that its evidence supports and moves up only when someone verifies it.
| Rung | What qualifies | What a seller may say | What a seller may not say |
|---|---|---|---|
| 1. Detected and dated | A provider record with its evidence type and last date | "Your site loaded a tag from this vendor as of the date shown" (website evidence) | That the account is a customer or uses the product today |
| 2. Inferred | Job-posting or install-record evidence, or a score below the top | "Your team has been hiring around this technology" | That the stack is confirmed, or that the product is in use |
| 3. Confirmed | The buyer stated it, or a seller verified it on a call or in a source the account controls | The fact, as the buyer gave it | Anything beyond what the buyer said |
Opinion: most outreach errors in this category come from rung 1 evidence worded as rung 3. A message that names a competitor product as if confirmed is wrong the first time the detection was a stale tag. See technographic data for B2B targeting for how stack signals qualify accounts and technology change sales signal for reading changes over time.
From API Row to Sales Action
A stored row becomes a sales action only after four steps, each with an owner.
- Pull. RevOps schedules the API call for a defined account list and writes each response into a Passport. Wappalyzer's documentation distinguishes cached results from live scans; TheirStack and BuiltWith return their own dates. Record the date you called as well.
- Gate. Apply a recency rule to the last date, per evidence type, and drop records outside it. Choose the window from your own data.
- Route. A record that passes goes to a seller queue with its rung. Removing existing customers and open deals happens here.
- Act and confirm. The seller researches, wording any claim to its rung, and records whether the buyer confirmed. A confirmation moves the record to rung 3.
For the wider enrichment flow around this, B2B data enrichment covers the contact side.
The numbers below belong to an invented company called Marlowe Metrics, which sells a warehouse-sync tool and wants accounts that use a specific data warehouse. They are made up to show the arithmetic and are not a result from any company.
| Marlowe Metrics, one pull, invented | Accounts |
|---|---|
| Target accounts looked up | 200 |
| Accounts with a record for the warehouse product | 64 |
| Records with a last date inside the 90-day window | 41 |
| Removed as existing customers or open deals | 12 |
| Routed to sellers at rung 1 or 2 | 29 |
| Confirmed by the buyer on a first call (rung 3) | Counted from calls, not from the pull |
The pull supports a question and a dated opening line. It does not support the sentence "you use this warehouse", which only the buyer can confirm.
The Known-Stack Pull: A Test to Run Before You Buy
The Known-Stack Pull is a bench test. Pick a set of accounts whose stack you already know from your own customers or from buyer statements. Call each candidate API for the same domains. For each known technology, record whether it was returned, its last date and its score. Then record what the API returned that you did not expect and check a sample by hand. This tests the provider on your market without relying on its own coverage figures.
Where Lead Seeker, Percepture and Pyra Fit
Lead Seeker is not a technographic data API. It sits after the stack record: Lead Compass reads your website, ICP and intent themes to surface opportunity picks with public sources where available, and a search returns verified people at the accounts you describe with the public signal behind each one. Read how Lead Seeker works for the flow, and the best B2B contact database guide for the contact layer that a stack record needs.
Percepture, where Bob Generale is President, runs B2B intent data services. Its guide on intent data to identify sales qualified leads covers where a timing signal sits next to fit. Pyra, which Bob co-founded, sells a paid pilot of one workflow with approval gates; it fits the Pull and Gate steps if you want an agent to apply the recency rule and write Passports, with a person approving anything sent to an account.
Limitations
- The devices are editorial methods, not benchmarks. The Field Passport, the Stack Claim Ladder and the Known-Stack Pull are this guide's own structure.
- Documentation describes a method, not a result. A documented confidence rule explains how a score is made, not whether the underlying technology is in use.
- "Not stated" is scoped to the page. It means the page read does not say, not that the vendor lacks the field.
- API documentation changes. Fields, plans and versions can change; read the current documentation before building a pipeline.
- The example is illustrative. Marlowe Metrics and its counts are invented and are not measurements.
- A company record is not a person record. A technology detected for a company describes the company; writing it onto a contact row turns it into an inference about that person.
Frequently Asked Questions
What is a technographic data provider API?
It is an interface that returns the technologies a company is detected or inferred to use, by domain lookup or by searching for a technology. Providers differ in evidence type, dates and score definitions, so the response is only as useful as your understanding of what produced it.
Which technographic API fields matter most?
The technology and category, the evidence type, the first and last dates, the meaning of any score, and the account key used for the lookup. Provider-specific extras such as TheirStack's job counts or HG Insights' location counts add context but do not replace the dates and evidence type.
How fresh is technographic API data?
There is no common cadence. BuiltWith returns first and last detected dates, Wappalyzer defaults to results verified within two months, TheirStack gives first and last dates found from postings, and Demandbase states only a regular refresh. Read the last date on each record and record the date you pulled it.
Does a technographic confidence score mean the account uses the technology?
No. BuiltWith's score follows fixed rules about dates and domain type, TheirStack's rating reflects job-posting mentions, and Cognism's match score describes how well a record matched. Each is a statement about how the record was produced.
Can a technographic record be written onto a contact?
It can be stored on the company. Placing it on a person's row turns a company-level detection into an inference about that person, so label it that way and keep it out of messages that state it as fact.
How to Read the Tables
The Field Passport, the Stack Claim Ladder, the Known-Stack Pull and the Marlowe Metrics example are this guide's own editorial methods, not vendor documentation or benchmarks. Marlowe Metrics is invented and its numbers are illustrative. "Fact", "Inference" and "Opinion" labels mark the difference between what a source states, what follows from it and what the author recommends. Source dates are the dates each source gives for itself. This is an October 2026 snapshot.
Sources
- Cognism, What is Technographic Data? API & Targeting Guide (May 26, 2026).
- ZoomInfo Pipeline, Technographic Data: The Complete B2B Guide for 2026 (Jul 6, 2026), and Company Enrichment API.
- AI Ark, Top 10 B2B Technographic Data Providers Compared in 2026 (Jan 19, 2026).
- Crustdata, Technographic Data Providers: How They Compare and How to Choose (Feb 23, 2026).
- Datarade, Technographic Data APIs.
- Demandbase, B2B technographic data.
- BuiltWith, API documentation, Domain API v26: fields, parameters and the confidence scoring rules.
- Wappalyzer, Technology lookup API.
- TheirStack, How we source tech stack data and Technographics API.
- HG Insights, Understanding HG Data.
- TechnologyChecker, Technographic Data API.
- PredictLeads, Technographic data via API, flat files, webhooks and MCP.
- 6sense, API Overview (updated Jul 10, 2025).
- Clay University, BuiltWith overview.
- Percepture, How to Use Intent Data to Identify Sales Qualified Leads and B2B Intent Data Services. Percepture is a company Bob Generale leads.
- Pyra, Pricing and paid pilot page. Pyra is a company the author co-founded.
- Lead Seeker, Lead Compass and Pricing: the free-leads offer, the 14-day Pilot and "No auto-spend". Lead Seeker publishes this page.
About the Author
Bob Generale is President of Percepture. He works across SEO, AI search, digital PR, sales intelligence and AI-powered revenue systems, with a focus on connecting visibility, buyer intent and sales action.
Next Steps
Take ten accounts whose stack you already know and run the Known-Stack Pull against two providers. Write a Field Passport for every returned record, then mark which rung each one supports. To start from the account and the person, try Lead Compass or start a free Lead Seeker trial.