I Just Wanted an API for domain → contacts

At some point, if you work with enough websites, you end up with a list of domains.

Maybe they came from a directory, a marketplace, an app store, a spreadsheet, or some crawler you wrote.

Then you want to know who is behind them.

That sounds simple.

So you write a script.

Fetch the homepage. Look for email addresses. Check /contact and /about. Parse mailto: links. Collect LinkedIn, X, Instagram, GitHub, and whatever else is linked from the site.

For some websites, that is enough.

For many others, it isn't.

You find a company LinkedIn page, but no person.

You find a founder's name, but no email.

You find hello@company.com, but what you actually want is the person running the company.

Then the script starts getting bigger.

Website crawling becomes social profile discovery.

Social profiles become people matching.

People matching becomes email pattern inference.

And then you have another problem: just because john.smith@company.com looks plausible doesn't mean it is real.

What started as:

domain → contacts

slowly turns into a small research pipeline.

There are already mature products that solve parts of this problem. But most of the time, I did not want a full prospecting or sales workflow.

I just wanted to pass a domain into a function and get structured contact information back.

That is what I started building ScoutLayer for.

The first step is intentionally boring: inspect the website itself and extract what it already exposes publicly.

Emails.

Phone numbers.

Contact pages.

Social profiles.

People mentioned on About or Team pages.

If there are useful signals, the next step is to follow them.

A company profile can lead to a person.

A person can lead to other public profiles.

Known people and known emails can reveal how a company formats its professional email addresses.

The difficult part is not generating possible answers.

That is easy.

The difficult part is deciding when there is enough evidence to return one.

If a company has a founder named John Smith, these are all plausible:

john@company.com john.smith@company.com johnsmith@company.com jsmith@company.com

But “plausible” is not the same as “known”.

So I am trying to make ScoutLayer conservative.

A public source is stronger than an inference.

A known email pattern is stronger than a generic guess.

Multiple signals agreeing on the same person are stronger than a name match.

If the evidence is weak, returning nothing is often better than returning the wrong person.

That is basically the idea behind ScoutLayer.

Not a CRM.

Not an outreach tool.

Just a small API for turning a website into useful contact data.

I wanted domain → contacts to feel like a primitive I could drop into a script.

So I built one.