Pricing

from $8.50 / 1,000 domain scoreds

Lead List Qualifier - Contact, Hiring & Tech Signals

Prioritize company domains with transparent contact, hiring, technology, and SEC-name signals. Get score contributions, evidence confidence, identity gaps, and a review action - not invented buyer intent.

Pricing

from $8.50 / 1,000 domain scoreds

Rating

0.0

(0)

Developer

Tim Zinin

Actor stats

Bookmarked

Total users

Monthly active users

20 days ago

Last modified

Lead List Qualifier — Domain Hotness Scorer

Score a list of company domains for outbound-readiness. Four built-in scanners run in-process for every domain — tech stack, active hiring, funding mentions and contact reachability — and combine what they find into one transparent hotness score. No child Actor is invoked and there is no second Actor charge.

Lead List Qualifier: buyer input to evidence-backed action

What you get

One hotness score (0-96) per domain, with a full text breakdown of exactly which signals contributed and how many points each one added — never a black-box number.
Signals combined: contact info found on the site, hiring momentum + role keyword matches, ecommerce/sales-tool detection, and SEC funding-filing mentions.
Honest about uncertainty: a guessed hiring-board token is checked against the board's public owner signal when one is available. A confirmed mismatch is shown for diagnosis but contributes no score; unavailable evidence stays explicitly unverified rather than being silently promoted to a match.
Domains with zero signal from all four sources come back free (not charged) — you only pay when we actually found something to report.
Runs on Apify: call it from the API, export to JSON/CSV/Excel or push straight into your CRM/outreach pipeline.

Lead List Qualifier: evidence-to-action workflow

How to run it

Click Try for free — no card needed on the free plan.
Paste up to 25 domains into Domains to qualify.
Optionally set Role keywords (e.g. sales, marketing) to flag domains currently hiring for those roles.
Hit Start and pull the scored list from the dataset.

Pricing

Pay-per-event: $0.005 per run start + $0.01 per domain scored. A domain with zero signal from all four sources, or one we couldn't check at all (all four sources unreachable), is returned but never charged. 10 domains scored cost about $0.11 (the one-time start fee plus 10 billed rows).

Input

Field	Required	What it does
`domains`	yes	Up to 25 company domains to score, e.g. `"stripe.com"`.
`role_keywords`	no	Words to match against open job titles (default: `["sales","marketing"]`).
`company_name_overrides`	no	`{"domain":"correct-slug"}` — override our guessed ATS token/company name for specific domains (see limitation below).

{
    "domains": ["stripe.com", "shopify.com"],
    "role_keywords": ["sales", "marketing"]
}

⚠️ Important limitation: guessed company identity for 2 of the 4 signals

Two of the four signals (contact info, tech stack) work directly off the domain you give us — no ambiguity there. The other two (hiring activity, funding mentions) need a company NAME or ATS token, not a domain, so by default we guess one from the domain itself (stripe.com → stripe). This guess can attach an unrelated company's data to your domain. Verified live: qualifying example.com (which has no real hiring-board presence at all) returned "strong hiring, 21 open roles" — because some UNRELATED company happens to sit under the token example on one of the three job-board providers we check. Similarly, querying "stripe" against public funding filings surfaces real SEC filings that merely contain the word "stripe" in an unrelated fund's name (e.g. "Rockefeller Stripe LP"), not Stripe Inc. itself.

Every row tells you the input path via matchBasis ("guessed-domain" or "buyer-override") and the hiring ownership result via attributionConfirmed (true, false, or null) plus attributionEvidence. A false hiring match is excluded from scoring. null means the public board did not expose enough evidence, not that ownership was confirmed. If you know the real ATS token or legal name for a domain, pass it via company_name_overrides to remove the guesswork for that domain — though even then, a name match on public filings is never proof of identity (see matchedFundingFilings — always check it yourself before treating funding mentions as fact).

Output

Full signal found (real output, live run 30.07.2026):

{
    "domain": "stripe.com",
    "found": true,
    "hotnessScore": 78,
    "scoreBreakdown": [
        "contact info found on the site (+15)",
        "aggressive hiring (+38)",
        "113 open role(s) matching your keywords (+15)",
        "11 SEC filing(s) mention \"stripe\" — UNVERIFIED (+10)"
    ],
    "reachable": true,
    "emailsFound": 1,
    "phonesFound": 3,
    "hiringMomentum": "aggressive hiring",
    "openRolesCount": 540,
    "matchedRolesCount": 113,
    "techStackCount": 2,
    "ecommerce": null,
    "cms": null,
    "fundingMentionsCount": 11,
    "fundingConfidence": "low — name-substring match on public SEC filings against a guessed slug, NOT a verified link to this domain; see matchedFundingFilings",
    "matchedFundingFilings": [
        { "company": "Pantera Opportunities Fund LP Stripe", "filedAt": "2026-07-24", "url": "https://www.sec.gov/Archives/edgar/data/2147228/000090266426003236/0000902664-26-003236-index.htm" }
    ],
    "companySlugUsed": "stripe",
    "identityConfidence": "guessed",
    "matchBasis": "guessed-domain",
    "attributionConfirmed": true,
    "attributionEvidence": { "method": "greenhouse-board-name", "requestedDomain": "stripe.com", "signal": "Stripe", "detail": "greenhouse's board name matches stripe.com." },
    "techStackChecked": true,
    "contactsChecked": true,
    "hiringChecked": true,
    "fundingChecked": true,
    "partial": false,
    "partialReason": null,
    "error": "",
    "summary": "stripe.com — hotness 78: contact info found on the site (+15); aggressive hiring (+38); 113 open role(s) matching your keywords (+15); 11 SEC filing(s) mention \"stripe\" — UNVERIFIED (+10).",
    "checkedAt": "2026-07-30T10:36:08.928Z"
}

No signal found (real output, live run 30.07.2026 — free, not charged):

{
    "domain": "zzqfakenonexistentdomain999999.example",
    "found": false,
    "hotnessScore": 0,
    "scoreBreakdown": [],
    "error": "",
    "summary": "zzqfakenonexistentdomain999999.example — no signal detected from any of the four sources (checked: techStack, contacts, hiring, funding).",
    "checkedAt": "2026-07-30T10:39:46.032Z"
}

Field	Meaning
`found`	`true` only when `hotnessScore > 0` — the billable outcome.
`hotnessScore`	0-96 heuristic index, sum of the components in `scoreBreakdown`. Not a percentage or a guarantee.
`reachable`, `emailsFound`, `phonesFound`	From the built-in contact scanner.
`hiringMomentum`, `openRolesCount`, `matchedRolesCount`	From the built-in public job-board scanner, keyed on `companySlugUsed`.
`techStackCount`, `ecommerce`, `cms`	From the built-in website technology scanner.
`fundingMentionsCount`, `fundingConfidence`, `matchedFundingFilings`	From the built-in SEC filing scanner — always check `matchedFundingFilings` yourself, see the limitation above.
`identityConfidence`	`"guessed"` or `"override"` — see the limitation above.
`matchBasis`, `attributionConfirmed`, `attributionEvidence`	How the ATS token was chosen and whether the board's public owner signal matched the requested domain. `null` is unknown, not confirmed.
`techStackChecked`/`contactsChecked`/`hiringChecked`/`fundingChecked`	Whether that source's own call succeeded this run (independent of whether it found anything).
`partial` / `partialReason`	`true` when some (not all) of the four sources failed to respond — the score is still computed from whatever did answer.
`error`	Empty string when the check completed (including "nothing found"); non-empty only when ALL FOUR sources failed to respond.

Other tools we built

Related tools for adjacent workflows in B2B lead generation and data enrichment.

Actor	What it does
B2B Lead Enricher	Pair it in the B2B lead generation and data enrichment workflow: Turn a list of company websites into sales-qualified lead cards: detected tech stack, a rough revenue...
Company Profile Lookup	Pair it in the B2B lead generation and data enrichment workflow: Turn a domain or company name into one unified company card: website tech stack (CMS, ecommerce, key tech)...
Intent Signal Aggregator	Pair it in the B2B lead generation and data enrichment workflow: Is this company in-market right now? Combines public hiring activity (Greenhouse, Lever, Ashby) and recent...
Counterparty Risk Rollup — Sanctions, Courts, Registry, Hiring	Pair it in the B2B lead generation and data enrichment workflow: One call, one row per counterparty: sanctions screening (OFAC + EU), legal-entity registry (GLEIF),...
Company Hiring Radar	Pair it in the B2B lead generation and data enrichment workflow: Pull every open role a company is hiring for from its public job board (Greenhouse, Lever, Ashby) and turn...

FAQ / Limitations

Why is my score lower than I expected? Check partial first — if some sources didn't respond this run, the score only reflects what did. Then check identityConfidence — a "guessed" slug for a distinctive company name usually still works; a common word as a domain label (like "example") is where guesses go wrong.

What this is NOT. This is not a verified company database and does not confirm that a domain and a matched hiring board or funding filing are the same legal entity — see the limitation section above. It is a prioritization heuristic, not proof.

Found a bug or need a custom scoring weight? Issues on the Actor's page.

Commercial guide: Lead List Qualifier — Transparent Multi-Signal Domain Prioritization

Rank a bounded domain list with in-process contact, hiring, technology, and public SEC-name signals while exposing every contribution, confidence penalty, and identity gap.

This guide is written for buyers, operators, analysts, and automation builders. It explains what the Actor observes, how to turn the Dataset into a controlled workflow, and where human verification remains mandatory.

The decision this product supports

Which submitted domains deserve the next unit of human research, based on observed public signals rather than invented buyer intent?

The Actor reduces collection and first-pass triage work. It does not remove responsibility for source verification or authorize an external business action. The commercial value comes from a structured, repeatable evidence layer: stable identity, observation time, source evidence, confidence, gaps, recommended action, and failure semantics travel with the raw facts.

Who uses it

User	Value
Founder-led sales teams	Prioritize a small account list before spending time on manual company research.
B2B agencies	Create an explainable first-pass queue for client-approved target domains.
Sales operations	Keep weighted signal strength separate from evidence confidence and route incomplete rows correctly.
Marketing researchers	Compare public contact, hiring, technology, and filing-name observations across a bounded cohort.
RevOps builders	Insert a deterministic scoring layer before enrichment, verification, and human qualification.
Small businesses	Decide which potential partners or accounts to research first without buying a black-box lead database.

Input contract

Input field	How to use it
domains	Required list of up to 25 company domains. Each domain runs four bounded in-process source checks.
role_keywords	Optional words used to highlight matching open-role titles. They influence the observed hiring signal, not proof of purchase intent.
company_name_overrides	Optional domain-to-company-token mapping that reduces domain-derived guessing. It does not turn name-substring funding evidence into verified issuer identity.

Recommended first Input

{
  "domains": [
    "stripe.com",
    "shopify.com"
  ],
  "role_keywords": [
    "sales",
    "marketing"
  ],
  "company_name_overrides": {}
}

Start with this bounded example, inspect every Dataset field, and only then expand the scope. Input limits are product controls, not inconveniences: they make cost, completeness, and error handling visible.

Field dictionary

Field or group	Meaning
entityId, domain, inputRef, observedAt	Stable domain identity and observation context.
hotnessScore, qualificationBand	Weighted public-signal strength and routing band. The score is not confidence and is not a probability.
signalContributions, scoreBreakdown	Structured and readable explanation of every score component.
sourceStatus, sourceEvidence	Completion and evidence summary for contacts, hiring, technology, and funding-name checks.
confidenceScore, confidenceBand, confidenceRisks	Evidence quality after source failures, guessed identity, attribution uncertainty, and unverified filing-name matches.
attributionConfirmed, attributionEvidence, identityConfidence	Whether a public hiring-board owner signal supports the requested domain and how the lookup token was chosen.
fundingMentionsCount, matchedFundingFilings	Public SEC filing name mentions that remain explicitly unverified as issuer-to-domain identity.
partial, failureType, retryable, negativeSignals	Operational and evidentiary gaps that prevent a clean automated routing claim.
recommendedAction, actionPriority, safeToAutomate	Bounded next step. Automatic outreach remains disabled.

Common decision fields

Field	Operational meaning
recordType	The semantic row family. Use it to distinguish a business result from an advisory or terminal record.
schemaVersion	Version of the additive decision-intelligence contract. Pin or validate it in strict consumers.
entityId	Stable entity identity for deduplication and joins. It is not necessarily a legal identifier.
inputRef	The relevant submitted input reference after normalization.
observedAt	When the Actor observed or finalized the evidence. It is not necessarily the source publication time.
firstSeenAt and lastSeenAt	Always-emitted observation boundaries. Stateful monitors use the compatible baseline/current boundary. Stateless rows set both equal to observedAt for the current run; that equality does not establish historical tenure.
freshness	A structured statement about evidence age or availability, not a prediction. Its basis and age unit follow the source-specific field definition.
eventId	For monitors, the stable identity of one observed transition or monitor outcome. It is distinct from entityId.
before and after	For monitors, the bounded comparable snapshots used for the decision. Null means that side of a comparison was not honestly available.
changedFields and changeFlags	Machine-readable monitor deltas and normalized change labels. Empty arrays mean no supported changed field was established, not that every possible real-world fact stayed constant.
materialityScore and materialityBand	Magnitude of an observed monitor change when the Actor can calculate it. Materiality is separate from evidence confidence and may be unknown when the source lacks the required facts.
confidenceScore	Evidence support on a 0–100 scale. It is separate from materiality, lead score, or business value.
confidenceBand	Readable high/medium/low/unknown grouping of evidence support.
confidenceReasons	Observed facts that raise confidence.
confidenceRisks	Missing, partial, ambiguous, inferred, or conflicting aspects that reduce confidence.
confidenceConflict	Explicit consistency warning when structured evidence does not reconcile.
sourceEvidence	Source-linked observations supporting the row. Preserve this during export.
dataGaps	Important evidence the Actor did not observe or cannot establish. Keep these gaps visible in CRM, spreadsheet, and automation exports.
negativeSignals	Machine-readable risks or gaps. A negative signal is not automatically a negative business outcome.
recommendedAction	Bounded review label produced from the available evidence.
actionPriority	Suggested queue priority, not urgency guaranteed by the source.
actionReason	Plain-language explanation for the recommended action.
safeToAutomate	Whether the narrow recommended action is deterministic enough for automation. Organizational policy still applies.
failureType	Normalized terminal or partial failure classification. Null means no classified failure.
retryable	Whether a later retry may legitimately change an operationally incomplete result.
recommendation	Human-readable handling guidance, especially for terminal rows.

Evidence, confidence, and honest boundaries

What the evidence supports

The hotness score is the deterministic sum of visible contributions, not an opaque model output.
The four source checks run in-process; no hidden child Actor bill is introduced.
Hiring ownership mismatch is excluded from scoring rather than silently accepted.
A funding mention is disclosed as a name-substring observation, not a verified funding round for the domain.
Partial source coverage lowers confidence without rewriting the observed weighted score.

What this Actor never claims

The Actor does not prove buyer intent, budget, urgency, authority, or product-market fit.
It does not verify that a filing issuer and a domain are the same legal entity.
It does not guarantee a detected public contact is deliverable, consented, or owned by a decision maker.
It does not interpret hiring as a confirmed need for the user's product.
It does not recommend automatic outreach; every positive result remains a research lead.

Reading data gaps correctly

A data gap is part of the result. Nulls, partial flags, confidence risks, source failures, and unavailable fields must survive export. Removing these fields makes the remaining facts look more complete than they are. When two sources conflict or a required identity cannot be proven, lower confidence and keep safeToAutomate=false.

Source evidence is not permission

A public source proves only that a value or statement was observable at the recorded time and URL. It does not establish consent, contractual rights, legal status, accuracy after observation, or authorization for a downstream action. Your organization remains responsible for source terms, privacy rules, outreach policy, retention, and human review.

Decision policy and action routing

Action	How to use it
PRIORITIZE_MANUAL_REVIEW	Research high weighted-signal domains first, but verify identity, fit, contacts, and source evidence.
ADD_TO_RESEARCH_QUEUE	Keep the account in a medium-priority queue and close the most important evidence gaps.
LOW_PRIORITY_REVIEW	Spend limited research effort because only a weak observed signal is present.
REVIEW_PARTIAL_QUALIFICATION	Restore missing source coverage or resolve identity ambiguity before routing the lead.
NO_SIGNAL_DETECTED	Treat the result as no signal in the bounded checks, not proof of a bad account.
RETRY_SOURCE_CHECKS	Retry after technical source failure without treating the failure as negative account evidence.

Confidence is not attractiveness

confidenceScore answers “how strongly does the available evidence support this factual classification?” It does not answer “how valuable is this lead, property, account, or address?” A high-confidence negative fact may be commercially uninteresting; a low-confidence positive signal may deserve research but not action. Keep the concepts separate in dashboards, exports, and CRM fields.

Why safeToAutomate is conservative

safeToAutomate is intentionally false whenever the next step could amplify an uncertain inference. It may be true only for narrow deterministic actions explicitly supported by the row, such as suppressing an email with invalid syntax. A true value does not waive legal, privacy, consent, contractual, or organizational rules.

Retry policy

Retry when retryable=true and the failure is operational, such as a temporary source or DNS problem.
Do not endlessly retry deterministic invalid input, policy refusal, or confirmed absence.
A retry must preserve the original input reference and must not create duplicate downstream actions.
Budget exhaustion is not negative evidence about the entity. Resume only the unprocessed scope with an authorized budget.
A failed Actor run is an operational event. Never transform it into “no listing,” “no contact,” “bad lead,” or “invalid email.”

Commercial use-case playbooks

1. Founder account triage

Goal. Score a handpicked list, inspect contribution and confidence side by side, then manually research the strongest evidence-backed accounts.

Recommended runbook.

Define the submitted cohort and write down why it is in scope.
Start with the smallest useful Input and preserve the exact run ID.
Inspect the Dataset overview before exporting anything.
Check failureType, retryable, completeness indicators, and confidenceBand.
Open the relevant sourceEvidence or source URL for material rows.
Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
Record the analyst's final disposition in the destination system.