Team Page People Extractor Executives Names Titles Clay

🔎 What can Team Page People Extractor do?

Give it a company domain and it returns the people that company publishes about itself on its own team, leadership or about page: names, job titles, and the exact page each one came from.

No profile network, no aggregator, no login, no third party database. Every row traces back to a page the employer published.

📦 What you get	⚙️ Features and integrations
👥 Names and published job titles, exactly as written 🪜 Normalized seniority and department for filtering 🔗 source_url on every row, so any name is checkable 🧾 31 flat fields, snake_case, two output grains	🌐 Eleven team and leadership paths probed at once 🧬 Structured data path as supporting evidence 🧊 14 day cache, with a skipCache override ⬇️ Export to JSON, CSV, Excel, HTML or XML

Bought by outbound teams building contact lists from first-party sources, and by recruiters and researchers who need an auditable trail back to the company's own page.

🚫 This is not a contact database and it does not find email addresses. It reads what a company publishes about its own staff. No email is ever attached to a named person, and no first.last@domain pattern is ever guessed. If you need a person level work email, use Work Email Waterfall Finder.

💡 Why use Team Page People Extractor?

If you need	Read these fields
A named executive to open with	full_name, job_title, seniority
Proof the person is really there	source_url, affiliation_confidence
To route by function	department, seniority
One row per company instead of per person	people_json, person_1_name through person_5_title
To tell "nobody there" from "could not read"	company_people_count, fetch_status
A dedupe key across runs	person_key

🧭 A dedicated team page beats a general about page, and the row says which you got

Dedicated team and leadership pages are preferred. A general about page is read only when no dedicated page produced anybody, and everyone found on one is labeled medium confidence.

That distinction is load-bearing. In the build sample, one large company's about page returned two real people with real titles who are almost certainly not its employees. affiliation_confidence is how you keep them out of a sequence.

Pages that come back identical are collapsed before extraction. One company in the test set served the same leadership page at three different paths, which is why pages_reached and pages_distinct are separate fields.

📋 What data can Team Page People Extractor extract?

31 fields across the two grains. The ones buyers use:

Field	What it holds
full_name, first_name, last_name	The published name, split
job_title	The title exactly as published, never rewritten
seniority	Fixed ladder: founder, c_level, vp, director, head, manager, other
department	Normalized function, read from the published title only
source_url, source_path	The page the person was published on
affiliation_confidence	high from a dedicated team page, medium from a general about page
extraction_method	Which path produced the person
person_key	Stable dedupe key, domain:name
company_people_count	How many people the company published
pages_attempted, pages_reached, pages_distinct	What was tried, what opened, what was unique
fetch_status, fetch_error	ok, no_team_page, partial or unreachable
people_json, person_1_name … person_5_title	Company grain only: everyone found, plus the five most senior flattened

⚠️ 0 and null are different answers. company_people_count: 0 means the pages were read and nobody was published. null means nothing was readable. This actor never collapses them. In the same spirit, a plain 404 is not an error: a company that does not publish /people has not blocked you.

🛠️ How to find a company's leadership team

1. Open the Input tab and put a bare domain in domain.
2. Leave output_grain on person for one row per person, which is what most Clay tables want.
3. Set seniority_filter if you only want decision makers.
4. Click Start.
5. Check affiliation_confidence and source_url before you use a row.

🧪 Using it in Clay

Add it as an Apify enrichment and map your domain column to domain. Every input is accepted as a string, which is what Clay sends.

If you are enriching a company table and want exactly one row back per row sent, set output_grain to company. You get people_json holding everyone found plus the five most senior names and titles flattened into columns.

🎚️ Filtering by seniority

seniority_filter runs over the normalized seniority field, not the raw title. job_title is always returned exactly as the company wrote it, so CEO, Founder, Owner stays intact while the row still filters as founder. Founder is checked before C level on purpose, because a founder is the more useful label to an outbound team.

💵 How much does it cost to extract a team page?

You pay per person found. A company with no readable team page costs nothing beyond the run.

Plan	Price per person found
Free	$0.006
Bronze	$0.0057
Silver	$0.0054
Gold	$0.0051

There is also an Actor start event at $0.00005, charged once per run per GB of memory.

💳 In company grain the charge is once per person in the array, not once per row. One returned row carrying seventeen people bills seventeen events. Set max_people if you want a ceiling; anything dropped is logged with the count.

⌨️ Input

Everything is on the Input tab. The options worth explaining:

Field	Type	Default	What it does
domain	string	required	Bare company domain.
output_grain	string	person	person for one row per person, company for one row per company.
seniority_filter	string	all	Keep only people at or above a rung on the seniority ladder.
max_people	string	50	Ceiling per company. Dropped people are logged with a count.
include_emails	boolean	false	Return emails found on the page, attached to the company only.
skipCache	string	false	true forces a fresh crawl past the 14 day cache.

📤 Output

Exportable as JSON, CSV, Excel, HTML or XML. One row per person by default:

{
  "full_name": "Monty Deel",
  "first_name": "Monty",
  "last_name": "Deel",
  "job_title": "Chief Executive Officer",
  "seniority": "c_level",
  "department": "general",
  "source_url": "https://swishdata.com/about/leadership/",
  "source_path": "/about/leadership",
  "extraction_method": "markup_heuristic",
  "affiliation_confidence": "high",
  "company_domain": "swishdata.com",
  "company_people_count": 17,
  "pages_attempted": 11,
  "pages_reached": 5,
  "pages_distinct": 2,
  "fetch_status": "ok",
  "fetch_error": null,
  "person_key": "swishdata.com:monty deel",
  "run_date": "2026-08-09T21:24:42.972Z"
}

💡 Tips

• Filter on affiliation_confidence: "high" before you sequence anybody. It is the single cheapest quality gate on this actor.
• Use person_key to dedupe across runs and across domains.
• Leave include_emails off. See Known limits for what those addresses actually turn out to be.
• Use company grain when the actor is one column in a company table, and person grain when you are building a contact list.

⚠️ Known limits

About 6 companies in 10 give us anybody at all. Measured on eight real companies spanning enterprise to small contractor: five returned at least one person, four returned a full leadership list, three returned nothing. If a company does not publish a team page, this actor cannot invent one.

We only see what a company publishes about itself. No profile network, no login, no third party database. That is the point of this actor and it is also its ceiling: most companies publish their executives and almost none publish their whole staff.

Check affiliation_confidence before you trust a row. People found on a general about page are marked medium, because an about page can name customers, advisors and case study subjects alongside employees.

The same page often lives at several URLs. One company in the sample served its leadership page at three different paths. Those are collapsed to one before extraction.

HTTP 200 is not always the page you asked for. One large company returns 200 for /leadership, /about and /about-us and serves the same generic marketing page on all three. When that happens you get zero people from those paths rather than four invented ones.

Emails are off by default and you should probably leave them off. Across three domains that published an email on a team page, we found one role mailbox, one placeholder in example content, and one literal user@domain.com template string. Not one was a real person's address.

Titles are returned exactly as published, and the seniority ladder reads that string. A bare Partner maps to c_level, which is right at a law firm or a fund and too senior at a company that uses the word differently. When the rung matters, read job_title as well.

You are billed per person, not per company. A company with seventeen executives bills seventeen times from one crawl. A company with none bills nothing.

What this actor will not collect, enforced in code and covered by tests: no email attached to a named person, ever, not behind a flag. No guessed email patterns. No phone numbers, photographs, image URLs or biographies. No inference of any personal attribute beyond the fixed seniority and department maps, which read the published title and nothing else.

❓ FAQ

Can it get me email addresses for these people?

No, and that is a build rule rather than a missing feature. When include_emails is on, addresses attach to the company row only, because nothing on these pages proves which address belongs to whom.

Why did a company return nothing?

Either it does not publish a team page, or the pages were not readable. fetch_status tells you which: no_team_page means pages were read and nobody was found, unreachable means nothing opened.

Does it use a proxy?

No. It runs direct with full browser headers and reports blocks rather than routing around them. The headers are required, not an optimization: two of the eight test domains return a challenge page to a bare user agent and the real leadership page to the full header set.

How fresh is the data?

Cached for 14 days, keyed by domain, grain, seniority filter and the email flag. Leadership pages change on a quarterly cycle. Set skipCache to "true" to force a fresh crawl.

How do I get a person removed?

Email privacy@mambamindsetgrowth.com with the person's name and the company domain. Records are purged within 14 days.

🧩 Want other GTM data?

Mamba Labs builds custom actors for B2B go-to-market teams. The public versions of that work live here on the Store, so our users get the same tooling we build under contract.

🧑‍💼 GTM Hiring Signal Scraper	🧱 Tech Stack Detector
📡 B2B Buying Signals Aggregator	🔑 Job Board Keyword Scanner
🔗 Domain to LinkedIn URL Resolver	🎯 ICP Fit Scorer
📋 Job Posting Monitor	📬 Domain Deliverability Checker
🏢 Company Firmographic Enricher	🌐 Company Social Presence Mapper
🪪 Company Identity Resolver	💰 Funding and Press Signal Scanner
🔄 Company Change-Event Feed	👤 People Finder and Email Verifier
🚀 Prospect Engine	🤖 AI Tooling Detector
📮 Outbound Stack Detector	📝 Publishing Frequency Tracker
✉️ Work Email Waterfall Finder	⏩ Sequencer Lead Push
🏅 Workplace Program Detector	🧭 Company Discovery List Builder

Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything.

🛠️ Need something custom built for you or your team? Tell us what you are trying to find and we will build it. Talk to Mamba Labs.

🆘 Support

Something wrong, or a company the actor reads incorrectly? Open an issue on the Issues tab with the domain and the row, and we will look at it.

ℹ️ Personal data, sourcing and removal. This actor returns names and job titles that companies publish about their own staff, read directly from the company's own website with robots.txt honored. That is personal data under GDPR. Mamba Labs processes it on your instruction; you decide what happens to it next and you are responsible for that use, including establishing your own lawful basis. To have a record removed, email privacy@mambamindsetgrowth.com with the person's name and the company domain. Records are purged within 14 days.

Built by Mamba Labs.