Company Enrichment — Domain to Company Profile, With Sources

Turn a list of domains into company profiles — and every field tells you the URL it came from.

Name, description, logo, on-domain emails, phone, postal address, social profiles, tech stack. No API keys. No data broker. Everything is read from the company's own public website, so you can click the source and check it.

---

Why the sources matter

Most enrichment returns a confident row you cannot verify. When it is stale or wrong, you find out from a bounced email or a prospect who left two years ago. Here every populated field looks like this:

"name": {
  "value": "Apify",
  "source": "https://apify.com/",
  "how": "schema.org Organization name (JSON-LD)"
}

And a missing field is an honest null plus the pagesRead list — meaning we looked at these pages and it was not published there, which is a different and more useful claim than silence.

Input

{ "domain": "stripe.com" }

Bulk — the normal case:

{
  "domains": ["stripe.com", "apify.com", "vercel.com"],
  "followSubpages": true,
  "maxSubpages": 3
}

Bare domains, www., and full URLs all work. Up to 200 domains per run.

Option	Default	What it does
followSubpages	true	Also read /contact, /about, /impressum style pages — where addresses and emails usually live. Much better coverage.
maxSubpages	3	How many extra pages per domain.

Output

{
  "domain": "apify.com",
  "website": "https://apify.com/",
  "ok": true,
  "fieldsFound": 7,
  "pagesRead": ["https://apify.com/", "https://apify.com/about", "https://apify.com/contact"],
  "jsonLdOrganizationFound": true,
  "name": { "value": "Apify", "source": "https://apify.com/", "how": "schema.org Organization name (JSON-LD)" },
  "emails": { "value": ["support@apify.com", "hello@apify.com"], "source": "https://apify.com/contact", "how": "page text, filtered to the company domain" },
  "technologies": { "value": ["HubSpot", "Google Analytics", "Next.js", "Intercom"], "source": "https://apify.com/", "how": "signatures in the delivered HTML" },
  "social": { "linkedin": { "value": "https://www.linkedin.com/company/apify", "how": "schema.org sameAs (JSON-LD)" } },
  "phone": null,
  "address": null
}

Pricing

Event	Price
Domain enriched	$0.02

You are not charged for: a domain whose site could not be fetched · an invalid domain · domains skipped because the run timeout was approaching. One charge per domain no matter how many of its pages we read.

1,000 domains = $20.

FAQ

Where does the data come from? The company's own website only: schema.org / JSON-LD Organization markup, OpenGraph and meta tags, mailto:/tel: links, visible text on contact and about pages, and technology signatures in the delivered HTML. Nothing is bought in, so nothing is silently years old.

Why is phone or address sometimes null? Because the company did not publish it in a machine-readable place on the pages we read. We only claim an address when it comes from structured PostalAddress markup — guessing one out of body text produces confident nonsense, and a wrong address is worse than none. Check pagesRead to see exactly where we looked.

Are the emails real? They are the addresses published on the company's own site, filtered to that company's domain (so no stray someone@gmail.com from a testimonial). They are role addresses like support@ or hello@ more often than personal ones. This is not a personal-email finder and does not attempt to be.

How is this different from the other enrichment actors? Provenance, and the absence of a data broker. You can audit any row in one click. If that does not matter for your use case, a bulk broker feed may suit you better — we would rather say that than pretend to be something else.

Can it find employee counts or revenue? Only when the company publishes them as structured data (numberOfEmployees, foundingDate, vatID/taxID are all read when present). Most do not. We do not estimate them.

Does it respect the sites it reads? It fetches a small number of pages per domain with a normal timeout and an identifying user agent, and it reads only what a browser would receive. It does not attempt logins, paywalls or bulk crawling.

Limits, stated plainly

• Public website data only — no broker, no private records, no personal-email guessing.
• Addresses require structured markup; we will not infer one from prose.
• Phone numbers come from JSON-LD or tel: links only, for the same reason.
• Tech detection is signature-based on the delivered HTML: it is evidence of a signature, not an audit of a company's whole stack.
• Sites that block server-side requests, or render everything client-side with an empty initial HTML, will return few fields. The record says so rather than inventing them.

---

Built by Broke to Built — a human-supervised AI team. Questions: eli@broke2builtai.com, answered fast.