LinkedIn Decision Maker Email Finder

The Actor finds a company's C-level, VP, Head, and Director staff and proposes a work email address for each. A person is included only when their headline binds them to a current role at the target company; ex-employees, unrelated name-drops, and similarly named companies are excluded rather than returned and left for the buyer to filter. No LinkedIn account or session cookie is required.

Email addresses are not looked up from a directory. The Actor learns the company's address format from addresses the company has already published — commit metadata on its public GitHub repositories, or its own site — and proposes each person's address by applying that format to their name. The real addresses the format was learned from ship with the result, so the format can be checked rather than trusted.

Accepted input

Field	Type	Default	Description
target_company	array of strings	["Stripe"]	Required. One line per company. A name, a LinkedIn company URL, or a website — all work.
verify_emails	boolean	false	Confirm each address against the company's mail server.
search_depth	integer	3	How many batches of seniority titles to sweep, 1–5. Each batch adds meaningful run time per company, so a higher value trades speed for a fuller roster.
max_candidates	integer	3	How many ranked candidate addresses to return per person, 1–5.
maxItems	integer	100	Maximum decision-makers saved across all companies. 0 removes the limit.
email_domain	array of strings	[]	Override. Leave empty unless the company mails from a domain other than its website.
github_org	array of strings	[]	Override. Leave empty unless the company publishes code under an unrelated name.

{
  "target_company": ["Northwind Robotics"],
  "search_depth": 3,
  "verify_emails": true
}

That is the whole input. The company's email domain and its GitHub organisation are worked out from the line you typed, and every row reports the domain that was used, so a wrong one is visible rather than silent. The two override fields exist for the rare company those lookups get wrong; supply one against several companies and it applies to all of them, or match them by position.

Response fields

One record per decision-maker.

Field	Contents
target_company	Company this person was found at
company_domain	Email domain used to resolve addresses for this company
name	Name shown on the related LinkedIn profile
headline	Current headline or organization text on the profile
seniority	c_suite, vp, head, or director, read from the headline
department	Function read from the headline, e.g. sales, engineering, finance
profile_url	Public LinkedIn profile URL
matched_title	The seniority title whose search matched this person
email	Best-match work email, or null when no address could be proposed
email_confidence	0–1, how much to trust this specific address
email_status	best_match, guess, or not_found
email_candidates	Ranked alternate addresses, each with its own format rule and confidence
email_pattern	The company's email format, e.g. first.last
email_pattern_rule	The full rule, including how surnames, hyphens, and accented characters are handled
email_pattern_evidence	Real addresses at this company the format was derived from
discovery_source	Which search index surfaced this profile

{
  "target_company": "Northwind Robotics",
  "company_domain": "northwindrobotics.com",
  "name": "Priya Shah",
  "headline": "VP of Engineering at Northwind Robotics",
  "seniority": "vp",
  "department": "engineering",
  "profile_url": "https://www.linkedin.com/in/priyashah",
  "matched_title": "VP",
  "email": "priya.shah@northwindrobotics.com",
  "email_confidence": 0.94,
  "email_status": "best_match",
  "email_pattern": "first.last",
  "email_pattern_rule": "first.last (surnames=all, given_hyphen=collapse, family_hyphen=collapse, diacritics=ascii)",
  "email_pattern_evidence": ["alex.chen@northwindrobotics.com", "morgan.lee@northwindrobotics.com"],
  "discovery_source": "brave"
}

Confirming a current role

A search snippet naming the target company is not proof of employment there. Checked against a naive version of that same check on a live run, 255 rows carried the company's name, and 230 of them were not that company's staff: 213 were unrelated mentions with no employment relationship, 11 named a former employer, and 6 belonged to a different company that happened to share the same leading word. All 230 are excluded here rather than shipped and left for the buyer to sort out; only headlines that bind the person to a current role at the named company are kept.

search_depth widens the search by seniority band rather than by page depth. At the default of 3, the Actor sweeps chief-officer titles, then revenue-adjacent leadership, then VP-level titles. 4 adds Head and Director titles; 5 adds Founder, President, and General Manager. A run returning strong C-level and VP coverage but no Head or Director rows has not exhausted the company — it has not yet swept the batch those titles are in.

How the email address is proposed

The Actor never assumes a format such as first.last. It first collects confirmed (name, email) pairs the company has already published — public commit authorship on its GitHub org, and addresses listed on its own site — then learns which format explains the largest share of that confirmed set. Coverage of that free ground truth is uneven and sector-dependent: it is common for software companies and for firms that publish staff directories, and it can be entirely absent for others. Where it is absent, the Actor still ranks candidate formats by how companies in general tend to render names and returns those, at lower confidence and email_status: "guess".

Confidence is computed per person, not per company. A domain-wide "this company uses first.last" says nothing about how that company renders a compound surname, a hyphenated given name, or an accented character — those are learned separately, so two people at the same company with the same format can carry different confidence. Where the confirmed sample is small or splits across more than one format, the Actor reports that as low confidence and a guess status rather than defaulting to a single assumed pattern; the alternative — reporting one address with unearned certainty — is the failure mode this field exists to avoid.

Verified addresses

With verify_emails enabled, an address is returned as email_status: "verified" only when the mailbox is confirmed to exist.

Some company domains accept mail addressed to anything, so no service can confirm a mailbox there. The Actor detects this before spending anything, reports it on each row as domain_verifiable, and does not charge the verified add-on for those companies. About four domains in ten behave this way.

Without verify_emails, addresses are best matches derived from the company's format and are not checked against the mail server.

The pattern add-on that resolves a company's format is charged once per company, and only when a format is actually derived. A company where no confirmed address could be found, or where GitHub and site harvesting turn up nothing, is not charged for pattern derivation — the decision-maker rows it does yield are billed on their own.

Frequently asked questions

Are the returned email addresses verified? No. Each is the best-match address for a format learned from the company's own published addresses, applied to the person's name. email_pattern_evidence carries the real addresses that format was derived from, so the rule behind a proposal can be checked directly instead of taken on trust.

Why does email_confidence differ between two people at the same company? The company-level format is one thing; rendering a specific name into that format is another. Compound surnames, particles (van, de, von), hyphenated names, and accented characters are each handled by a rule learned separately, so a straightforward name can score higher than an unusual one even though both use the same base pattern.

What does email_status: "guess" mean? The proposed address came from ranking candidate formats generally, not from a format confirmed against this company's own published addresses. This happens when the company has too little free ground truth — no useful GitHub history and nothing published on its own site — to learn a company-specific rule from.

What happens when a company yields no decision-makers? The run completes, logs the outcome for that company, and moves to the next one. Nothing is charged for a company that returns no rows.

Do I need to supply email_domain and github_org for every company? Only target_company is required. A single email_domain or github_org is applied to every company in the run; supply one per company to pair them positionally instead. Leaving email_domain empty for a company returns its people without attempting to resolve email addresses at all.

Is a LinkedIn account or session cookie required? No. Only public profile headlines and search results are read.

Related Actors

Actor	Purpose
LinkedIn Company Scraper	Company page details — industry, size, headquarters — by handle or URL
LinkedIn Profile Scraper	Full profile details for a known username or URL
LinkedIn Related User Scraper	Profiles LinkedIn shows alongside a seed profile
LinkedIn Jobs Scraper	Job search by keyword and location