Give it a website and it reads the site to work out what that company actually sells: product categories, brand and product names, whether there is a checkout and which platform runs it. Every fact comes back with the page it was read from, so a claim can be checked rather than believed.
It is built for the case where you have a list of URLs and no idea what is behind them. That includes the awkward ones. A URL is often not a company's own site at all, and the honest answer to "what does this company sell" is sometimes "this page belongs to somebody else".
The common use is disqualification rather than discovery: finding out which names on a list already sell what you sell, before you spend anything approaching them.
Inputs
- websitesarray of strings
- Bare domains or full URLs. acme.com, www.acme.com and https://acme.com are treated as one company rather than three.
- inputDatasetId and websiteFieldstring
- Read a column of URLs straight out of a previous run's dataset instead of pasting a list, which is how it is used inside a larger pipeline.
Outputs
- company_name and description
- What the site says it is.
- sells
- The product categories the site actually lists, in its own words rather than a fixed taxonomy.
- sells_online and ecommerce_platform
- Whether there is a real checkout, and what it runs on.
- brands and product_examples
- Named brands and specific products found on the pages read.
- hosted_on
- Set when the page belongs to a platform rather than to the person who listed it. This is the field that separates a company's own site from a profile on somebody else's.
- an evidence view
- The page behind every claim, plus which pages were read: company_name_evidence, sells_evidence, shop_evidence, platform_evidence, pages_read and pages_read_urls.
Delivered as Apify dataset, CSV, dataset from a previous run.
What it does not do
It does not check that a site belongs to the person or company you associate it with, because it cannot. It reads the page it is given and reports what that page sells. Point it at a profile on a shared platform and it will accurately describe the platform: a GitHub profile has been read as selling professional services and code linters, which is GitHub's own marketing navigation, correctly read off a page that does not belong to the person who listed it. This is why hosted_on exists and why it should be read before the sells field is trusted.
Storefront hosts are the deliberate exception. A page on Etsy, Gumroad or Ko-fi is somebody else's platform in exactly the same way, but there the URL is itself evidence of selling, so the answer is meaningful rather than misleading.
It follows a redirect to wherever it lands, which is correct behaviour and occasionally surprising. A shortened affiliate link resolves to the retailer it points at, and the retailer's categories are what get reported. The facts are accurate and the attribution is not, which is a difference the evidence view exists to make visible.
It reads a sample of pages per site, not the whole site. A company that describes its actual business on a page the crawl does not reach will be described from the pages it did reach.
It reports what a site sells, never whether that competes with you. Deciding what counts as a competitor is a judgement about your market and is deliberately left outside the Actor, because a rule that fired on "has a shop" would disqualify every creator selling t-shirts, which is most of the successful ones.
Where it is used
- Removing candidates who already sell what you sell, before an outreach list is built rather than after a reply.
- Turning a column of unlabelled URLs into something you can filter, sort and read.
- Telling apart a company's own website from a profile page on a platform, which is a distinction most lists do not carry and most tools do not make.
- Checking whether a prospect has a real checkout, and on which platform, before pitching anything that integrates with one.
Can be composed with
- YouTube Creator Finder produces website URLs, which this accepts as an input.
These are separate programs. Neither calls the other, and this one works on its own. A composition is something you or an agent wire up, not something that happens behind the scenes.
From an agent
It runs as an Apify Actor, so any MCP client can call it through Apify's hosted server at mcp.apify.com. Nothing extra was built for this. It is not loaded by default, so an agent either finds it through Apify's search tool or is given the name:
salomon-dot-labs--company-enrichment-scraper
The description a model reads before deciding to call it is the same sentence that heads this page. Every input listed above is optional, so a model can start it with far less than a full configuration.
Worth knowing when you wire it up: the call returns a pointer rather than the rows. An agent gets the dataset id, the item count and the available field names, then fetches the results in a second step. That is how Apify exposes every Actor, not something particular to this one, and it means budgeting two round trips per answer.
It runs on Apify. Inputs, output schema and pricing are all on the listing, and a run can be started from the browser without writing any code.
Open on Apify