UK B2B Leads Verifier

What does UK B2B Leads Verifier do?

UK B2B Leads Verifier checks a bought UK lead list against the Companies House register and returns one verdict row per lead. Companies House is the UK's public register of companies. A lead that claims a UK company is matched on its name, number or website stem; its email domain, website and phone are checked alongside. Each judged row carries 26 fields: the verdict, a match score, the matched company's number, status, registered address and dates, and the register page to open as proof. Paste the list in as columns or point it at a CSV or JSON file, then press Start.

On a measured run of 100 leads, all 100 came back judged: 79 verified ok, 15 read dissolved, 4 in_distress and 2 not_on_register. A judged row costs $0.005.

Who uses UK B2B Leads Verifier

Who	What they run it for
A founder or sales-ops lead who just paid for a list	Check every row before the first send instead of spot-checking a sample by hand.
An outbound team about to spend sender reputation	Suppress dissolved and in-distress companies before the campaign, not after the bounces.
A buyer disputing a bad list	The dead rows come back with the reason and the register link, ready to take to the seller for a refund.
A calling team working a phone column	Valid numbers come back with a line type; invalid ones are flagged before anyone dials.

Features

• Register verdict on every UK-signalled lead. The claimed company name, company number or website stem is matched against Companies House. A UK signal is a company number, a +44 phone, a .uk domain or a UK legal form such as ltd or plc in the name. A row carrying no UK signal is never searched, so a non-UK company can never collect a false UK verdict.
• Four checks per lead, none behind a paywall. Register status, MX records on the email domain, a live-website probe and a phone-number parse with line type. No paid lookups and no API keys.
• Columns or a file. Paste emails, urls, companies and phones as parallel columns, or set leadListUrl to a CSV or JSON list. An Apify dataset URL from a lead-finder run works directly.
• No login, no browser, no key. Every check is a plain logged-out GET or a DNS lookup, one request per lead. The register's developer API serves 0 requests a day without a key; the public search this Actor reads needs none.
• Polite register reads. Lookups run one at a time with a pause between them, under the register's 120-requests-a-minute guideline. A refusal is backed off once, not hammered.
• Misses are free and named. A failed register read, a block, a timeout or a row with nothing to judge is pushed uncharged, with the reason on it.

What you can count on

• You pay only for rows the run judged. A row it could not judge is pushed as an uncharged ITEM_STATUS row, so you see the miss and are never billed for it.
• Every row is charged only after it is written to your dataset; a row you cannot see is never billed.
• A run that finds nothing returns one NOTHING_TO_JUDGE row that says so, never an empty dataset.
• A spending limit stops the run cleanly with a STOPPED_EARLY row saying how many rows were returned and how many were not.
• Every run writes a RUN_SUMMARY entry with rowsFetched, rowsPushed, rowsCharged and duplicatesDropped, so a short run and a broken one are told apart.
• If the register changes what it answers, the run fails with the error in the log. It never returns rows full of nulls and calls it success.
• No value is invented: a field the register does not show is null, and this page says which.

Why this one

• The most-used alternative on this platform, run on its own default board on 2026-09-15, returned 1 row where this Actor returned 4 on the same input. Its row left every field it declares empty: the company, the name, the email, the phone, the source.
• No start fee of ours. Start fees across the Store run from $0.00001 to $0.10 before the first row comes back. This Actor declares no start event; only Apify's standard platform start charge of $0.00005 applies, once per run.
• A miss is free and explained. The row still lands in your dataset, uncharged, with the failure named on it.
• The judged rate is measured, not promised: a list of 123 leads the product had never seen came back 122 of 123 judged, every judged one ok, the one it could not read written uncharged, worked in runs under the 100-lead cap, read without a browser.
• Every matched row carries evidence_url, the live register page behind the verdict. It filled on 98 of the 100 judged rows in the measured run.

What data does UK B2B Leads Verifier return?

One row per lead. A real dissolved verdict from a run looks like this:

{
  "email": "info@bae.co.uk",
  "domain": "bae.co.uk",
  "status": "dissolved",
  "match_score": 80,
  "reason": "SOCIETY OF BRITISH AEROSPACE COMPANIES (THE) (00143447): dissolved on Companies House; the email domain accepts mail; the website answers; the phone number is valid (fixed_line)",
  "error": null,
  "found": true,
  "is_active": false,
  "claimed_company": "british aerospace",
  "matched_name": "SOCIETY OF BRITISH AEROSPACE COMPANIES (THE)",
  "normalised_status": "dissolved",
  "status_as_of": "2026-09-18T02:55:41.988Z",
  "phone_number_status": "valid",
  "phone_line_type": "fixed_line",
  "website_answers": true,
  "email_domain_accepts_mail": true,
  "dead_reason": "dissolved on the register 2023-01-17",
  "evidence_url": "https://find-and-update.company-information.service.gov.uk/company/00143447",
  "company_status": "dissolved",
  "company_number": "00143447",
  "company_type": "private-unlimited",
  "date_of_creation": "1916-03-29",
  "date_of_cessation": "2023-01-17",
  "address": {
    "locality": "London",
    "postal_code": "SE1 7SP",
    "address_line_1": "9 Albert Embankment",
    "premises": "Salamanca Square"
  },
  "register_description": "00143447 - Dissolved on 17 January 2023",
  "row_type": "ROW"
}

The verdict vocabulary

status carries one of five charged verdicts, or a miss word on an uncharged row:

status	What it means
ok	Matched on the register and active there. On a weaker match (match_score under 90) the verdict is about the entity matched_name names, so check it is yours.
dissolved	Matched on the register; the entry shows it dissolved, by its status word or, when the entry carries no status word, by a closed company type such as converted-or-closed named on dead_reason.
in_distress	Matched; the register shows liquidation, administration, receivership or similar.
not_on_register	The UK register was searched and no entry matched the claim. It means "no UK company matched", not "the company does not exist".
unverifiable	Judged, but the register could not confirm the row: the lead carried no UK signal to search on, the register was down and never asked for this row, or the matched entry carried no status the run could classify. Its match_score is null. A row whose own register read was attempted and failed is a miss, not this verdict, and is free.
fetch_failed, blocked, timeout, aborted, not_found, error	The run could not judge this row. Pushed so you see it, never billed.

Two words are easy to confuse and worth a second look. not_on_register is a verdict: the register was searched and nothing matched. not_found is a miss: the row carried no email, website, company or phone to judge, and it is free.

Every field, in order

Field	What it carries
email	The email the lead row claimed, echoed back so the verdict lines up with your list. Null when the list carried no email column.
domain	The domain the lead was judged on, taken from its website or else from its email address.
status	The verdict, or the miss word on an uncharged row.
match_score	Register-match confidence: how strongly the register answer supports the verdict, 0 to 100. A score of 95 or more is the claim itself, name or number. Under 90 the match is weaker: the register name extends the lead's name, shares only part of its words, or the row's own geography says it may be a different company. matched_name and evidence_url name and link the entity the verdict is actually about on those rows. A fixed middling value on not_on_register; null on unverifiable, where a number would claim confidence the register never gave.
reason	One sentence naming the matched company and what each check found, readable without opening the register.
error	What failed, on an uncharged miss row only. Null on every judged row.
found	True when a register entry matched the claim.
is_active	True when the matched company is active on the register right now.
row_type	ROW for a judged lead, ITEM_STATUS for an uncharged miss, NOTHING_TO_JUDGE or STOPPED_EARLY on a status row.
register_description	The register's own one-line description of the company, verbatim: such as "Incorporated on 27 November 1947", truncations included.
address	The registered office address the register publishes, as an object of region, locality, postal code and address lines.
company_type	The register's type word for the company, verbatim: ltd, plc, converted-or-closed and the like.
company_status	The register's own status word: active, liquidation, dissolved and so on.
date_of_creation	The incorporation date the register shows.
company_number	The register's permanent number for the matched company.
date_of_cessation	The dissolution date, when the register's entry names one. A dissolved row whose entry carries no date stays null.
claimed_company	The company your lead row claimed, echoed from the input: a name or a UK company number.
matched_name	The register's legal title for the entry it matched, so a trading name still lands on the right company.
normalised_status	The normalised register read: active, dissolved, in_distress, no_match, unchecked when the register's answer could not be read or classified, or not_applicable when the row carried no UK signal and the register was not asked.
status_as_of	When the verdict was computed, ISO-8601.
phone_number_status	valid or invalid as a number. Whether a line rings is not claimed.
phone_line_type	The line type where the number parses: mobile, fixed_line, toll_free, voip and similar.
website_answers	Whether the website answers HTTP at all. A 403 still counts as an answer; false means nothing answered.
email_domain_accepts_mail	Whether the email's domain publishes MX records. The mailbox itself is never probed.
dead_reason	On a dissolved or not_on_register verdict, which check killed the row, with the register date when there is one. An in_distress company is still live and an unverifiable one was never confirmed, so they carry none.
evidence_url	The register page to open to see the evidence behind the verdict.

Status rows carry four fields of their own: reason says why the run ended that way, and rowsFetched, rowsReturned and rowsRemaining give the counts.

On the measured run's 100 judged rows the register fields filled nearly throughout. matched_name, company_number, company_type, register_description and evidence_url filled on 98 of 100, company_status on 97, and address and date_of_creation on 95. claimed_company, domain, status, match_score, reason, found, is_active, normalised_status and status_as_of filled on all 100. date_of_cessation filled on 14 of the 15 dissolved rows, and dead_reason on 17 (the 15 dissolved and 2 not_on_register rows).

One field stays null on every judged row by design, not by accident:

Field	Why it stays null
error	It fills only on an uncharged miss row, where it says what failed. A judged row has nothing to report.

The Console's Overview view hides error; the All fields view and every export carry it.

How much does it cost?

The price is $0.005 per judged row, billed as the row-judged event, and only after the row is written to your dataset. A dead lead is still a judged row: a dissolved or not_on_register verdict is the answer you paid for, and an unverifiable row was judged too. Miss rows, status rows and dropped duplicates are never billed.

Leads in the list	If every lead judges
100	$0.50
1,000	$5.00
10,000	$50.00

The coverage figure is measured on a different list: a set of 123 leads the product had never seen came back 122 of 123 judged, worked in runs under the 100-lead cap, with no browser. The one row it could not read was written uncharged, which is the only way a run bills under the ceiling. The 100-lead run this page cites elsewhere is a different measurement. A run judges at most 100 leads, so longer lists are worked in runs of 100. Apify also bills its standard apify-actor-start charge at $0.00005 per start event, one event per GB of run memory with a minimum of one; at this Actor's 256 MB default that is one event per run. This Actor adds no start fee of its own.

How do I use UK B2B Leads Verifier?

1. Open the Actor page and press Start.
2. Feed it leads one of two ways. Paste the emails, urls, companies and phones columns, keeping the rows parallel so position 1 in each array is the same lead. Or set leadListUrl to a CSV or JSON list, including a dataset URL from a lead-finder run.
3. Leave maxItems at its default of 100, which is also the cap, or set a lower number of rows the run may return.
4. Press Start. Verdict rows land in the dataset as they are judged.

Example input, the same four leads the input form ships with:

{
  "emails": ["press.office@tesco.com", "info@carillion.co.uk", "info@maplin.co.uk", "sales@zzqx-nonexistent-example.com"],
  "urls": ["https://www.tesco.com", "https://www.carillion.co.uk", "https://www.maplin.co.uk", "https://zzqx-nonexistent-example.com"],
  "companies": ["TESCO PLC", "CARILLION PLC", "04220419", "ZZQX EXAMPLE NONEXISTENT LIMITED"],
  "phones": ["+44 1992 632222", "+44 20 7946 0958", "", ""],
  "maxItems": 100
}

The same run through the Apify API is one call:

curl -X POST "https://api.apify.com/v2/acts/Pradio~b2b-leads/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["info@carillion.co.uk"], "companies": ["CARILLION PLC"]}'

Input

Input	Type	Default	What it does
emails	array	four example rows	The email each lead row claims. Its domain is checked for MX records; the mailbox is never probed.
urls	array	four example rows	The website each lead claims, fetched once to see whether it answers. Its domain also helps match the company on the register.
companies	array	four example rows	The company name or UK company number each row claims. A registered name or a number matches sharpest.
phones	array	four example rows	The phone number each row claims, checked for validity and line type.
leadListUrl	string	none	A CSV or JSON lead list read instead of, or as well as, the columns above.
maxItems	integer	100	The most rows one run returns, capped at 100. Leads beyond the cap are not judged.

The columns are parallel

emails[i], urls[i], companies[i] and phones[i] describe one lead. Any subset works. A lead with only a domain is still matched by the domain's name stem. A lead with only a phone still gets its number checked. A row with nothing usable comes back as a not_found miss, free.

leadListUrl

Point it at a CSV file or a JSON array of objects; an Apify dataset-items URL from a lead-finder run works directly. CSV headers are matched by the names list sellers actually use. The email column answers to email, e-mail or mail. The website answers to website, url or domain. The company answers to company, organisation or business. The phone answers to phone, telephone or mobile. Only those four columns are read. A contact's name, a job title or any other column in the file is never copied into a row. A list URL that answers with an error fails the run instead of returning an empty dataset.

Output

A run ends one of four ways, and row_type says which:

row_type	What it means
ROW	A judged lead. Charged.
ITEM_STATUS	A miss the run could not judge. Pushed so you see it, never billed.
NOTHING_TO_JUDGE	The input gave the run no leads: empty columns and no leadListUrl, or a file whose rows carried none of the four columns. One row, uncharged. A zero result is an answer, not silence.
STOPPED_EARLY	The charge limit was reached before every fetched row was pushed. The row carries rowsFetched, rowsReturned and rowsRemaining, so finishing and being cut short never produce the same dataset.

Every run also writes a RUN_SUMMARY entry to the run's key-value store: rowsFetched, rowsPushed, rowsCharged, rowsUncharged, duplicatesDropped, startedAt and finishedAt. It is the fast way to tell a short list from a broken run. When maxItems cuts a run short, rowsFetched against rowsPushed there shows what the list held against what came back.

What can you do with the data?

Take the dead rows back for a refund. Filter status to dissolved, in_distress and not_on_register, and dead_reason plus evidence_url itemise exactly which leads failed and on what evidence. On the measured 100-lead run that meant 15 dissolved rows, 4 in distress and 2 with no register match. That is the report a money-back guarantee asks for.

Clean a list before the first send. Suppress every row that is not ok, then read website_answers, email_domain_accepts_mail and phone_number_status on the survivors to drop any whose checks you would not send to. ok means the company is live on the register; the check fields are the deliverability read. 79 of the 100 measured leads verified active. The rest would have cost bounces, caller hours and sender reputation to discover the slow way.

Re-verify an ageing list. Companies dissolve between the day a list is bought and the day it is worked; 15% of the measured list already had. Upload last quarter's extract again and status_as_of dates every verdict, so a stale row is caught before it is sent.

Triage a dialling list. phone_number_status drops numbers that do not parse. phone_line_type splits mobiles from fixed lines and VoIP, so the team dials the rows worth dialling first.

Use UK B2B Leads Verifier with AI agents

$claude mcp add --transport http apify "https://mcp.apify.com?tools=Pradio/b2b-leads"

Paste that line into your agent's setup and it can start runs and read verdict rows as tools.

Personal data

Attribution. The register evidence on every row is public sector information from Companies House. Contains public sector information licensed under the Open Government Licence v3.0, at https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/.

Transparency. Verdicts derive from the public Companies House register and from DNS and HTTP checks on the details each lead claims. The basis for processing is legitimate interests: checking that business data sold as accurate is accurate. A data subject may object and request deletion of their particulars.

What a row carries. A verdict row carries the verdict and the matched company particulars it needs: company name, number, status and registered office address. It does not echo officers' dates of birth or home addresses. Officer or PSC names are not read at all; the register search returns company records only. Of the list you upload, only the email, website, company and phone columns are read. A person's name or any other column never reaches a row.

How the register is read. Logged-out plain GETs, no credential and no bypass, one page per request, with maxItems capped at 100 rows a run. A refused or failed read fails the run; it does not retry past a block.

Controller. You choose which list to upload and why, so the controller for the personal data in it is you or your organisation. The register data is published for public use under the licence above.

Release notes

• 0.1: first public build, a lead-list verifier on the Companies House register. Per-lead verdicts (ok, dissolved, in_distress, not_on_register, unverifiable) with the matched company's particulars and evidence link, MX, website and phone checks on the row, and a 100-lead cap per run.

Limits

• UK register only, and it only asks about UK-signalled leads. The register check is Companies House. A lead carrying a UK signal is searched. The signal is a company number, a +44 phone, a .uk domain or a UK legal form in the name. One that matches nothing reads not_on_register, which means "no UK company matched", not "the company does not exist". A lead with no UK signal is never asked and reads unverifiable with normalised_status not_applicable. A non-UK row can still match a same-named UK company, since overseas groups do register UK subsidiaries and branches. When the row's own domain or phone contradicts the UK claim, the match stands. Its confidence is capped, and reason says it may be a different company.
• 100 leads a run. maxItems is capped at 100 and the run judges no more than that. A longer list is worked in runs of 100, each billed for its own judged rows.
• The mailbox itself is never probed. email_domain_accepts_mail is an MX check on the domain, so a full or dead inbox still reads true.
• "Valid" stops at the number. phone_number_status and phone_line_type come from parsing the number itself. Whether the line rings is not claimed, and no carrier lookup is made.
• "Answers" is generous on purpose. website_answers is true when anything answers HTTP, even a 403 or a parked page. False means nothing answered at all.
• Free-mailbox emails never drive a match. A lead whose only company hint is a gmail address is never guessed at the register from the word "gmail".
• One refusal is backed off, not hammered. A 403 or 429 from the register pauses the run once. A second refusal marks the register down. The hit row is pushed free as blocked. Later rows are judged on the other checks with normalised_status set to unchecked.
• Reads are sequential. Register calls run one at a time with a pause between them, under the register's 120-a-minute guideline, so a large list takes a while. That is the polite speed, not a fault.
• Errors run towards naming a miss, never towards a fake verdict. A check that fails says so on the row rather than guessing. A field the register does not publish is null rather than filled.

Troubleshooting

I uploaded 50 leads but only 47 rows came back. Where are the rest? Two places to look. Rows sharing an email are de-duplicated before anything is billed, so repeats collapse to one row each. And maxItems caps how many rows are pushed. RUN_SUMMARY splits it exactly: rowsFetched, rowsPushed, duplicatesDropped.

The dataset has a single row and it is not a verdict. Is the run broken? No. That is a NOTHING_TO_JUDGE status row: the input gave it no leads. Check the columns are parallel arrays, or that leadListUrl answered and its headers were recognised.

A row says unverifiable with normalised_status not_applicable, but the company is real. The row carried no UK signal: no company number, +44 phone, .uk domain or UK legal form in the name. The UK register was not asked. The checks that did run (email domain, website, phone) are on the row. If the company is UK, give it a .uk website, a +44 number or its Companies House name and it will be searched.

A row says unverifiable with normalised_status unchecked, but the company is real. Either the register could not be read for that row, usually after it refused an earlier request and the run stopped asking, or the register answered with an entry whose status the run could not classify; company_status then carries the register's own word. The other checks still ran and are on the row. Re-run the list once the register is answering again.

The run ended with a STOPPED_EARLY row. Your charge limit was reached. The status row carries rowsReturned and rowsRemaining; raise the limit and re-run to see the rest. Rows already returned stay billed, and nothing after them is.

Something looks wrong? Report a problem through the Issues tab on the Actor's Store page and it gets looked at.

FAQ

Can I use integrations with UK B2B Leads Verifier? Yes. The dataset exports as JSON, CSV, Excel and more, so a dead-row report drops straight into a spreadsheet or a CRM import. Apify integrations such as Zapier and Make can start a run when a new list lands.

Can I use UK B2B Leads Verifier with the Apify API? Yes. POST the same JSON the input form takes to the Actor's run endpoint; the curl in the how-to section is the whole call. Runs, datasets and schedules are all reachable through the standard API and client libraries.

Can I use UK B2B Leads Verifier through an MCP server? Yes. The snippet in the AI-agents section registers this Actor with a compatible agent, which can then start runs and read the verdict rows.

Is it legal to check a lead list this way? The register half of each verdict is Companies House's public company search, read with a plain logged-out GET. That is public sector information licensed under the Open Government Licence v3.0, with no login and no bypass. The input side is a list you already hold. What you may do with it sits between you and its seller.

Not affiliated

UK B2B Leads Verifier is an independent tool. It is not affiliated with, endorsed by or connected to Companies House, Apify or any lead-list provider. Company data comes from the public register under the Open Government Licence v3.0.