New UK Company Detector — Official Incorporation Evidence and Lead Seeds

Find bounded recent active Companies House name matches and return official entity identity, incorporation freshness, confidence, evidence, enrichment gaps, and a review action.

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.

What you get

• Recent active UK company-name matches from the public Companies House search, bounded to the submitted lookback and first result page.
• Official company number and direct register URL, incorporation date, legal type, status, and locality-level address context.
• Evidence confidence, explicit enrichment gaps, an enrichment-first action, and a plain-language interpretation boundary on every row.
• A free explicit no-match or operational outcome instead of a silent empty Dataset.
• Run-level KVS OUTPUT reconciliation for normalized keywords, company deduplication, delivery, billing, withheld work, partial state, and replay safety.

The Actor uses pay-per-event billing. The automatic run-start event and each unique delivered company evidence row follow the prices shown in the live Apify pricing panel. Confirmed no-match and operational advisory rows are free while the Dataset event remains configured at zero. Current live pricing is authoritative.

The decision this product supports

Which recently incorporated UK entities match the submitted name themes, and what enrichment is still required before treating them as prospects?

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
Small-business service providers	Find recent entity formations relevant to an authorized geographic or thematic research campaign.
Accountants and formation services	Monitor bounded new-name cohorts and review official records before outreach.
B2B marketers	Use incorporation timing as a lead seed, then add website, industry, contact, and fit evidence.
Market researchers	Observe recent registered-name activity by keyword with exact source and first-page limits.
Agencies	Deliver an official-register seed list without presenting it as qualified demand.
Automation builders	Key workflows on company number and route explicit zero, partial, source, and budget outcomes.

Input contract

Input field	How to use it
items	Required list of up to 25 case-insensitive company-name keywords. Case variants are deduplicated.
windowDays	Incorporation lookback from 1 to 365 days, default 60.
maxConcurrency	Parallel keyword searches from 1 to 20.

Recommended first Input

{
  "items": [
    "capital",
    "consulting"
  ],
  "windowDays": 60,
  "maxConcurrency": 5
}

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, companyNumber, officialCompanyUrl	Stable official UK company identity and direct Companies House reference.
companyName, incorporatedOn, status, companyType, addressLocality	Public register facts returned by the bounded search row.
keyword, inputRef, matchBasis, searchWindowDays	Why the row was included and which query/window produced it.
observedAt, incorporationAgeDays, freshnessBand	Observation and incorporation-timing context.
partial, sourceRowsSeen, sourceRowsDropped, sourceDropReasons	Parser and bounded-result coverage disclosures.
confidenceScore, confidenceBand, confidenceConflict	Support for official identity or explicit no-match classification.
dataGaps	Website, industry, contacts, decision maker, and commercial fit still missing from an incorporation seed.
sourceEvidence, negativeSignals	Official register link and any partial/source/failure codes.
recommendedAction, actionPriority, safeToAutomate	Enrichment-first routing; automatic outreach remains disabled.
interpretationBoundary	Exact statement of what the official incorporation evidence cannot establish.
failureType, retryable, failureDiagnostics, recommendation	Confirmed no match versus source, schema, partial, pricing, and budget outcomes.
billing	Whether the row is billable, the linked event name, and the delivered evidence unit.

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.

Dataset and KVS OUTPUT

The default Dataset contains one row per unique delivered company number plus free search outcomes. If two submitted keywords return the same company, the billing mutex delivers and charges that company once in the run and increments duplicateCompanyCount instead of selling a duplicate row.

Read KVS OUTPUT before consuming Dataset rows. Its terminal status is COMPLETE, PARTIAL, or FAILED, with these reconciliation groups:

Field or group	Meaning
input.requestedCount / uniqueCount / duplicateCount	Raw submitted items and case-insensitive normalization.
attemptedCount / unattemptedCount	Keywords whose source request started versus scope left untouched.
successfulCount / failedCount	Keyword queries completed without versus with an operational source failure. These are keyword counts, not company-row counts; an explicit bounded no-match is successful processing.
discoveredCompanyCount / duplicateCompanyCount	Source company rows observed and repeated company numbers suppressed before billing.
deliveredRowCount / paidRowCount / localNonMonetizedRowCount / freeRowCount	Company and explanatory row delivery totals. Paid company delivery is accepted only when the exact result-found event counter increases by one around the linked push; aggregate receipt counts are diagnostic only.
withheldRowCount / budgetStopped	Known company rows withheld and whether the charge boundary stopped work.
sourceFailureCount / confirmedNoMatchCount	Operationally incomplete outcomes kept separate from explicit bounded zeroes.
fatalError / ambiguousDeliveryCount / replaySafe	Terminal failure and whether a blind retry could duplicate an uncertain delivery.

replaySafe=true means the completed run has no ambiguous push/charge receipt. It does not make an intentional new run free or prevent your CRM from creating a second external action. Keep the Apify run ID and use entityId as the downstream idempotency key.

Evidence, confidence, and honest boundaries

What the evidence supports

• A company row is parsed from an official Companies House public search result and includes its registration number.
• The incorporation date supports a timing classification within the submitted window.
• An explicit Companies House no-results marker supports no match for the bounded query.
• Dropped or malformed source rows make the result partial instead of silently disappearing.
• The official company URL provides the primary identity reference for manual enrichment.

What this Actor never claims

• The Actor does not prove buyer intent, trading activity, revenue, funding, website ownership, contacts, or product fit.
• It does not return the complete Companies House register or every matching page beyond its documented bounded result.
• It does not provide legal, credit, sanctions, director, beneficial-owner, or solvency conclusions.
• It does not treat a registered-office locality as the operating location.
• It does not authorize bulk outreach merely because an entity was recently incorporated.

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
ENRICH_COMPANY_BEFORE_OUTREACH	Open the official record and add website, industry, contact, identity, and fit evidence before any campaign decision.
NO_MATCH_IN_WINDOW	Record the explicit bounded no-match and adjust the query only if the business question requires it.
RETRY_OR_REVIEW	Retry operational source problems without treating them as no companies.
RAISE_BUDGET_AND_RESUME	Resume unfinished keywords after an authorized budget adjustment.
FIX_PRICING	Correct platform pricing configuration before paid result delivery.

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. New-business service prospecting

Goal. Find recent name matches, enrich official identities and public websites, then verify relevance and outreach basis.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

2. Accountant niche watch

Goal. Schedule narrow keywords, deduplicate by company number, and review newly observed entities in an internal queue.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

3. Agency lead-seed delivery

Goal. Deliver official identity, timing, evidence URL, and data gaps—not a “sales-ready” claim.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

4. Market theme observation

Goal. Count bounded keyword matches over comparable runs while disclosing first-page and source limits.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

5. Company-name screening

Goal. Use keyword matches only as discovery; manually inspect the official record to resolve ambiguous names.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

6. CRM new-entity staging

Goal. Key on companyNumber, keep incorporation facts immutable, and write later enrichment into separate fields.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

7. Partial parser audit

Goal. Quarantine sourceRowsDropped and schema-change outcomes before any count or lead delivery.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

8. No-match monitoring

Goal. Treat a confirmed no-match as query-specific and time-specific, then rerun on schedule if ongoing monitoring is authorized.

Recommended runbook.

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

Do not skip. A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

Integration recipes

All examples use placeholders. Keep the Apify token in a secret manager and never write it into a Dataset, README, screenshot, or client-side application.

cURL: start a run and wait briefly

curl -sS -X POST 'https://api.apify.com/v2/acts/zinin~new-company-detector/runs?waitForFinish=60' \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"items":["capital","consulting"],"windowDays":60,"maxConcurrency":5}'

The run response includes defaultDatasetId. Read clean JSON rows with:

curl -sS "https://api.apify.com/v2/datasets/$DEFAULT_DATASET_ID/items?clean=true&format=json" \
  -H "Authorization: Bearer $APIFY_TOKEN"

JavaScript with apify-client

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const input = {
  "items": [
    "capital",
    "consulting"
  ],
  "windowDays": 60,
  "maxConcurrency": 5
};
const run = await client.actor('zinin/new-company-detector').call(input);
const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });

for (const row of items) {
    console.log({
        entityId: row.entityId,
        confidenceBand: row.confidenceBand,
        recommendedAction: row.recommendedAction,
        safeToAutomate: row.safeToAutomate,
        failureType: row.failureType,
    });
}

Python with apify-client

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("zinin/new-company-detector").call(run_input={
    "items": [
        "capital",
        "consulting"
    ],
    "windowDays": 60,
    "maxConcurrency": 5
})

for row in client.dataset(run["defaultDatasetId"]).iterate_items(clean=True):
    print({
        "entityId": row.get("entityId"),
        "confidenceBand": row.get("confidenceBand"),
        "recommendedAction": row.get("recommendedAction"),
        "safeToAutomate": row.get("safeToAutomate"),
        "failureType": row.get("failureType"),
    })

Apify MCP call

{
  "name": "call-actor",
  "arguments": {
    "actor": "zinin/new-company-detector",
    "input": {
      "items": [
        "capital",
        "consulting"
      ],
      "windowDays": 60,
      "maxConcurrency": 5
    }
  }
}

Generic webhook consumer policy

1. Trigger on a terminal Actor run event.
2. Confirm the run status is SUCCEEDED before reading business rows.
3. Retrieve rows from defaultDatasetId.
4. Retrieve KVS OUTPUT and require an accepted terminal status and replay policy.
5. Reject or quarantine rows whose failureType is non-null unless your policy explicitly handles that failure.
6. Send safeToAutomate=false rows to a human-review queue.
7. Store entityId, observedAt, sourceEvidence, confidence, action, and the Apify run ID together.
8. Make retries idempotent by keying the destination on the stable entity ID plus the intended observation identity.

Where this fits in a practical stack

Destination	Recommended pattern
Apify Console	Use the visual Input form, start the run, then open the default Dataset overview. This is the fastest path for a one-off review and the best place to inspect evidence before automating anything.
Apify API	POST JSON input to the Actor run endpoint, wait or poll for completion, then read the default Dataset through the URL returned by the run object.
JavaScript client	Use apify-client from a Node.js service, pass the same JSON object as the Console Input, and preserve the returned run and Dataset IDs in your own audit log.
Python client	Use apify-client in a Python enrichment job, iterate Dataset items, and route rows by recommendedAction, confidenceBand, failureType, and retryable.
Make	Start the Actor from a scenario, wait for the run, retrieve Dataset items, filter unsafe or low-confidence rows, then insert review-ready rows into the destination application.
Zapier	Use an Apify run action or webhook trigger, fetch Dataset items, apply a Filter step, and send only review-approved fields into the next sales or operations step.
n8n	Use HTTP Request or Apify nodes, branch on failureType and retryable, keep a manual-review lane for safeToAutomate=false, and write sourceEvidence together with the business fields.
Google Sheets	Export the Dataset directly or append rows from an automation. Keep stable entityId as a hidden key so reruns update the correct record instead of creating ambiguous duplicates.
Airtable	Map entityId to a primary or deduplication field, store confidence and evidence in separate columns, and expose recommendedAction as the triage view.
Webhook	Configure an Apify webhook for terminal run states, retrieve the Dataset after SUCCEEDED, and treat FAILED or TIMED-OUT runs as operational events rather than negative business evidence.

A safe automation shape

The Actor is a collection and decision-support component. A production workflow should keep raw evidence, decision metadata, and business action in distinct layers:

1. Collect: run the Actor with explicit bounded input.
2. Validate: require a successful run and schema-valid Dataset rows.
3. Triage: branch on failureType, retryable, confidenceBand, and safeToAutomate.
4. Review: open source evidence for rows that may affect a person, campaign, investment, compliance decision, or customer record.
5. Act: execute only the action approved by your own policy and authorized operator.
6. Audit: retain run ID, Dataset ID, observation time, input reference, source evidence, and the final human decision.

This separation prevents a common automation error: turning “data was observed” into “a business action is justified.”

Operating guide

Before the first production run

1. Write the business question in one sentence: Which recently incorporated UK entities match the submitted name themes, and what enrichment is still required before treating them as prospects?
2. Confirm every submitted input is within your authorized scope.
3. Use the prefilled small example and review all returned row types.
4. Map stable identifiers, confidence, evidence, actions, gaps, failure, and retry fields into the destination.
5. Establish a human owner for review exceptions.
6. Set a run budget and output bound appropriate to the test.
7. Verify that secrets are stored only in the platform or workflow secret manager.

After every scheduled run

1. Check terminal run status and logs.
2. Compare the number of submitted entities, produced business rows, and advisory rows.
3. Review partial, unknown, conflict, and low-confidence buckets.
4. Inspect a sample of source evidence, including at least one positive and one negative result.
5. Confirm the destination deduplicated on the intended stable key.
6. Verify that no downstream action was triggered from an error row.
7. Track cost per useful reviewed row rather than cost per raw request alone.

Production monitoring signals

Monitor source-unavailable rate, partial-row rate, low-confidence share, missing evidence, retry volume, run duration, Dataset row count, and spend. A sudden shift may indicate source drift, input drift, or an upstream outage. Stop automation and investigate before accepting a new pattern as business truth.

Cost control

Start with one narrow and one control keyword, a 30–60 day window, and default concurrency. Inspect official URLs, duplicate identity, no-match rows, and partial markers before scheduling. Current live pricing is authoritative.

Use maxTotalChargeUsd when calling a monetized Actor if your workflow supports it. Treat a buyer-set cap as a hard safety boundary. If the cap stops work, the unfinished items remain unprocessed; they do not become negative results.

Buyer and operator acceptance checklist

Use this checklist before calling the workflow production-ready.

Product fit

• The business question matches: Which recently incorporated UK entities match the submitted name themes, and what enrichment is still required before treating them as prospects?
• The submitted entities were selected through an authorized process.
• A human owner understands the positive, negative, partial, and failure row types.
• The team accepts the boundaries listed in “What this Actor never claims.”
• The destination keeps evidence confidence separate from business scoring.

Input and run controls

• items is explicitly reviewed and bounded.
• windowDays is explicitly reviewed and bounded.
• maxConcurrency is explicitly reviewed and bounded.
• The first production-like run uses a small representative sample.
• A maximum charge or internal spend alert is configured where appropriate.
• The workflow records Actor ID, build/version, run ID, Dataset ID, and input hash.

Data handling

• entityId is mapped to an idempotent destination key.
• observedAt and source-specific time fields remain distinct.
• sourceEvidence, gaps, and nulls are preserved.
• Advisory and failure rows cannot enter the positive-results lane.
• Low-confidence and partial rows have a visible manual-review view.
• Retention and deletion rules match the type of data collected.

Action safety

• recommendedAction is treated as a review label.
• safeToAutomate=false blocks automatic external action.
• Consent, suppression, legal, contractual, and platform rules are evaluated downstream.
• A reviewer can trace a material action back to source evidence and run metadata.
• Retry logic cannot duplicate a downstream action.

Ongoing quality

• The team monitors failure, retry, partial, low-confidence, and empty-result rates.
• A source-drift threshold pauses the workflow for inspection.
• Sample evidence is manually reviewed on a recurring basis.
• Cost per useful reviewed row is measured.
• Documentation and field mappings are updated when schemaVersion changes.

Frequently asked questions

Is this a database?

No. It is an on-demand observation tool. Each run collects or evaluates the submitted scope and records evidence at that time.

Does a found row prove commercial interest?

No. A found row proves only the factual observation described by its fields. Buyer intent is never inferred.

Can I automatically contact every result?

No. Use recommendedAction as triage, verify the evidence and identity, and apply your own consent, privacy, suppression, and outreach rules.

Why is safeToAutomate often false?

Because a useful observation can still require identity, context, legal, or source verification before action. Conservative routing prevents false certainty from scaling.

What should I do with low confidence?

Open confidenceRisks and sourceEvidence, close the important gap, or keep the row in a manual queue. Do not hide the confidence field.

What does partial mean?

The Actor obtained some usable evidence but could not support a complete observation of the configured scope. Partial is not the same as empty.

What is a confirmed zero?

Only an explicit source or deterministic rule can support a confirmed absence. An outage, truncation, or unreadable response is not a zero.

Should I retry every failure?

No. Retry only when retryable is true. Invalid input, policy refusal, or deterministic classification should be corrected or handled, not looped.

Can I delete failure rows?

You can exclude them from a business-results view, but retain them in operational logs so Dataset completeness and retry decisions stay explainable.

How should I deduplicate?

The Actor suppresses repeated companyNumber values inside one run before linked delivery and billing. Downstream, use entityId for the entity and retain the Apify run ID so a repeated run cannot create an accidental second CRM action.

Can I treat confidence as conversion probability?

No. Confidence measures evidence support, not purchase probability, revenue, suitability, or expected return.

Can I change the recommended action?

Yes. It is an explainable default. Your downstream policy can be stricter, and should encode organization-specific authorization and risk tolerance.

How do I estimate cost?

Run the smallest representative input, inspect live event prices and run usage in Apify, then model the number of billable result events. The live pricing panel is authoritative.

Why use a small prefill?

It produces a cheap, fast, inspectable first run and reduces the chance of scaling a wrong input or workflow assumption.

Can I schedule it?

Yes. Use an Apify schedule, but make the destination idempotent and review changes in failure, partial, and confidence rates.

Can I export CSV or Excel?

Yes. Apify Datasets support common export formats. JSON is recommended when you need nested evidence and decision fields.

Can I send results to Sheets or Airtable?

Yes. Preserve entityId, confidence, evidence, gaps, actions, and failure fields instead of mapping only the headline value.

Can I use it from Make, Zapier, or n8n?

Yes. Start the Actor, wait for a successful terminal state, read Dataset items, then branch on decision and failure fields.

Can an LLM consume the output?

Yes, but pass the structured evidence and limitations together. Instruct the model not to invent missing facts and to cite sourceEvidence.

What happens when a source changes?

The run may become partial, unavailable, or fail validation. Monitor these rates and inspect logs before treating changed output as a real-world shift.

Does public mean unrestricted?

No. Public visibility does not remove source terms, privacy obligations, retention rules, or the need for a legitimate downstream purpose.

Is a source URL permanent?

Not necessarily. Store observation time and material facts because web content can change or disappear.

Can I rely on one row for a high-stakes decision?

No. High-stakes legal, financial, employment, compliance, safety, or personal decisions require appropriate primary evidence and qualified review.

How do I report a suspected parsing issue?

Provide the Actor run ID, a redacted input, affected field, expected source evidence, and whether the issue reproduces. Never include tokens or private data.

What does success mean?

A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.

Support information to include with an issue

Provide the public Actor name, Apify run ID, Dataset item index or stable entity ID, a redacted Input, the relevant source URL, expected behavior, observed behavior, and whether retrying produced the same result. Do not include an Apify token, API key, private customer record, or unnecessary personal data.

Related Actors

Actor	Use it after or alongside this Actor
B2B Lead Enricher	Add public company and contact-channel evidence after an incorporation seed passes review.
Website Contact Scraper	Extract public website contact points from a buyer-authorized company domain; it does not prove consent or mailbox ownership.
Company Lookup	Add broader company identity evidence while preserving source and confidence boundaries.
Funding Round Tracker	Check official SEC Form D evidence for relevant US fundraising research; it is a separate jurisdiction and source.
Email Verifier	Validate a supplied email's technical evidence after identity, collection basis, and outreach policy are established.

Final interpretation rule

A matching company row proves a recent official registered-name observation. It is a lead seed requiring enrichment, not proof of operations, budget, demand, or consent.