B2B Lead List Verifier

Check a lead list before spending time on outreach. Supply rows from a lead finder or Apify dataset IDs; receive each original row under source with technical checks under verification. This is an unofficial tool, not affiliated with, endorsed by, or sponsored by the websites or lead finders mentioned here.

What a check tells you

The Actor combines email syntax, public MX/A records, disposable-domain and role-address lists, company DNS, company website responses, supplied-name presence on public company pages, RDAP registration age, and a cautious SMTP catch-all estimate. These are public signals, not proof of mailbox deliverability, current employment, consent, or identity. It does not discover new people or fetch LinkedIn profiles. No authentication, CAPTCHA bypass, account pools, proxies, or paid enrichment APIs are used.

Only data supplied by the customer is processed. ntriqpro does not build, retain, combine, or resell a lead database from your inputs. Input and results remain in your Apify run storage, subject to your storage settings; manage retention and deletion there. The Actor holds working caches in memory, writes results to the run dataset, and stores only hashes, indices and billing state in the run checkpoint. It does not log contact details. Our applicable legal and data-processing obligations remain.

Submit only business-contact data you are authorized to process. You are responsible for lawful input, target terms, outreach rules and output use. Unlawful use, spam and phishing are prohibited. The standard Actor contract applies; this notice does not remove customer rights or our legal duties. Every result repeats the responsibility statement.

Input

Every top-level field is an array, including options. Supply rows, datasetIds, or both. Dataset rows run first. IDs must identify datasets your run can read. An unreadable dataset fails the run instead of claiming success. maxRows: [10000] applies across both sources, with an absolute maximum of 50,000.

{
  "rows": [{"email":"support@apify.com","company_domain":"apify.com"}],
  "datasetIds": [],
  "signals": ["email","domain","website","domain_age"],
  "maxRows": [10000],
  "timeoutMs": [7000],
  "retryCounts": [2],
  "disclaimerAck": ["accepted"]
}

For dataset input, use "datasetIds": ["YOUR_DATASET_ID"] and "rows": []. Automatic aliases cover code_crafter (email, full_name, company_domain), pipelinelabs (fullName, companyDomain) and microworlds (organization_primary_domain, organization_website_url). First/last name pairs are joined. emailFields, domainFields, nameFields and companyFields put your custom keys ahead of those aliases. Non-string alias values generate normalization warnings. Original keys, including upstream emailStatus and catch-all claims, stay in source and never override our checks.

An empty signals array means all six: email, domain, website, name_presence, domain_age, catch_all. websitePaths defaults to ["/about","/team"], checked only when a supplied name needs comparison. Optional pages stay on the final company origin. Robots exclusions and crawl delays are respected; a restriction can make coverage unknown. HTTP/DNS requests have bounded timeouts and up to two retries for temporary failures. Domain results are reused within a run; RDAP requests are serialized. No free-plan-specific cap is applied.

Results and limitations

Each input retains sourceDatasetId, sourceIndex, inputIndex and inputHash. verification includes normalized identifiers, syntax/MX/A flags, disposable/role/free-provider flags, company website status and redirects, checked page URLs, name presence, registration date/age, registrar, completed/unknown signals, risk reasons and the responsibility statement.

active_signals means the requested technical signals were favorable, not that outreach is permitted or will succeed. risky flags concerns such as a role address or a name absent from the checked pages. stale_or_invalid reflects specific negative technical evidence. unknown reports insufficient external evidence; blocked pages, DNS timeouts and RDAP limits are never positive findings. A missing name is not evidence of departure. HTTP 403 is not a company-closure verdict.

SMTP checks use a single bounded dialogue to the public MX and a random recipient estimate. They never send DATA or an email, authenticate, or retry the dialogue. Acceptance produces only likely with low confidence; rejection or an unavailable connection remains unknown. We do not claim a verified recipient mailbox or a definitive negative catch-all result. Lists and cached public signals can be incomplete or stale.

Duplicate identity includes normalized email, company domain, supplied name, company and website, plus dedupKeys (default ["email","companyDomain"]). An exact duplicate keeps its own source row and duplicateOfInputIndex; its verification is reused without another result charge. A different supplied name is checked separately. Only per-run deduplication is promised.

Pricing

The platform-managed apify-actor-start costs $0.001 per platform memory unit (one event per GB, minimum one) in all tiers. At the default 512 MB it is one event per run. This applies even to rejected input or failed runs. The code does not charge an additional startup event.

lead-checked applies once to each unique, completed check written to the dataset, including no-match and external unknown outcomes after the disclosed checks were attempted. Customer input errors, duplicate copies, notices, internal failures and retries have no result fee. Malformed or unsafe rows are marked invalid_input, remain unbilled, and cause a failed run with partial results. Internal errors remain internal_error and fail the run; they are not renamed as completed checks.

Plan	Start / memory unit	Completed unique check
FREE	$0.001	$0.005
BRONZE	$0.001	$0.004
SILVER	$0.001	$0.00325
GOLD	$0.001	$0.0026
PLATINUM	$0.001	$0.0026
DIAMOND	$0.001	$0.0026

Example at the FREE event rates and default memory: 10 unique completed rows cost $0.051, including startup. Eight positive checks and two completed no-match/unknown checks cost the same. Duplicate copies and rejected rows add no result charge. Actual owner runs and platform subsidies can differ; this example is a price calculation, not a claim that every run produces creator revenue.

On a spending limit the Actor stops publishing new paid results and leaves completed partial output plus a separate charge_limit_reached notice. An in-flight row can remain in the dataset with no result charge if the platform rejects that charge. Charge intent and platform counts are reconciled on a same-run restart. An ambiguous billing response fails closed without a second charge attempt; operator reconciliation may be needed. Already delivered results are preserved. A later new run is a new paid check, not a free resume.

Leave a review

A short review on the Reviews tab, good or bad, helps other people find this Actor and tells us what to build next. Found a bug or need a feature? Open an issue on the Issues tab and we'll look into it.