Director+ · Security · 200–2000
1B+412 match
A description, not a keyword
Build the list from a description
Seniority, department and company size combine and nest into one query instead of a list you assembled by hand. For go-to-market teams.
Find the people who match. Not the ones you already know.
Criteria in, current people out — searched live across the 1B+ person graph, not read out of a snapshot. Narrow to populations a general index does not carry: curated decision makers, developers and clinicians.
1B+Profiles searchable
45M+Decision makers
95M+Developers
3M+Healthcare
In production
Who already builds on it.
Platforms shipping their own products on these records today.
What you can search on
Describe a person you have not met.
Criteria combine and nest, so a search is a description rather than a keyword. The last two are the ones a general profile index cannot answer.
Now
Who they are today
Name, headline, summary, location, current title and employer, and seniority — the person as they are at the moment you ask.
Department, not job titles
Titles are normalised into departments and functions, so “Head of Data”, “VP Data” and “Data Lead” all answer one query instead of three.
Where they have been
Past employers and past roles with their dates, how long they stayed, and total years of experience.
Who just moved
People who changed roles recently — on its own, or combined with the company they moved into.
What they know
Skills, education with school, degree and field of study, and the certifications they hold.
The company they sit in
Industry, headcount and headcount band, company type, headquarters and domain — company criteria applied to the people inside.
Ours only
Which population
Narrow to the curated decision makers, to developers with real public activity, or to clinicians.
How they combine
Group criteria with and/or and nest them, exclude a list you already hold, match ranges and dates, or search a radius around a place.
Live or bulk
Ask the question, or hold the answers.
Search runs against the graph at the moment you ask. The dataset hands you the records to keep. Most teams end up using both, and the comparison is the honest way to work out which one you need first.
| People Search | People Dataset | |
|---|---|---|
| What you get | The people matching a description, returned per query. | The records themselves, delivered as files on your schedule. |
| Freshness | Live against the graph — results reflect it as it stands, not a snapshot. | A cut you hold, refreshed on the cadence you agree. |
| Use it when | The question is specific, changes often, or belongs to a user in your product. | You are running the same joins repeatedly and want the data in your warehouse. |
| Together | Hold the bulk cut for the joins you repeat, and use Search live over the same graph for the questions the file cannot answer yet. | |
How it works
Describe, run, hand off.
Search returns the people. Enrichment returns everything about them — which is why the fourth step exists rather than being folded into the third.
- 01Describe who you wantCombine and nest criteria — seniority, department, past employer, skills, population.
- 02LiveWe run it across the graphAgainst 1B+ profiles as they stand, not against a stored result set.
- 03Get the people who matchA list, with the identifiers you need to go further.
- 04Hand them to EnrichmentTurn the matches into full records — history with dates, education, activity.
Use cases
What teams describe, and what comes back.
Each of these is one search. The difference is only which criteria are doing the work.
Narrow to a population
Not in a general index
Search a population others do not hold
Curated decision makers, developers with real public activity, or clinicians — as a filter over the same graph. For teams selling to a specific world.
Works in · ships
S. Okafor2.4k stars
Built, not claimed
Find developers by what they have built
Languages, topics and public repository activity as criteria — real evidence rather than a self-declared skill list. For developer-tools teams and technical recruiting.
NorthwindHead of Data
Vertex LabsVP Data · new
Caught on the way in
Catch the people who just moved
Filter to recent job changes, on their own or inside a target account, and reach someone while they are still choosing tools. For sales and recruiting teams.
Vertex Labs1,400
The account, opened up
Open an account into the people in it
Start from the company and get the committee — who to reach, by department, at that specific employer. For account-led sales.
Your product · search
Your users, your UI
Ship search inside your own product
Offer the search to your users under your brand, with the list you already hold suppressed so nothing repeats. For platforms.
How you take it
However your stack wants to ask.
The same graph behind every surface — the difference is only who is doing the asking.
Real-time
Search API
Run a query at the moment of the question and get the people who match.
Agents
Skills and MCP
The same search inside Claude and ChatGPT, and any tool that speaks them.
Try it
Ember
A visual layer over the same APIs. Run real searches in a UI before anyone writes code.
Security and compliance
The graph is ours. The query stays yours.
We search and validate our own graph rather than reselling someone else’s, and the criteria you send are not retained as a list of who you are looking for.
Security & Trust Centre
EU & UK
California
India
Audited
FAQs
Search questions,
Search questions,
answered
How is this different from the People Dataset?
Search answers a question against the graph as it stands. The People Dataset hands you records to hold and query yourself. Same graph underneath — the choice is whether you want the answer or the data.
Are results live, or from a stored index?
Live. A search runs against the graph at the moment you ask, so a result reflects where someone is now rather than where a snapshot last recorded them.
How complex can a query get?
Criteria group with and/or and nest inside each other, so “director-and-above in engineering, at 200–2000 person fintechs, who moved in the last quarter” is a single query. Ranges, dates, a radius around a place, and “must match all of these” are all available, as is excluding a list of people you already hold.
Can we suppress people we already have?
Yes. Pass the profiles or names you already hold and they are removed from the results, so a search returns what is new to you rather than what you already bought.
Can we search, then get the full record?
Yes, and that is the usual pattern. Search returns the people who match; People Enrichment turns each one into a complete record with work history, dates, education and activity.
Can we narrow to developers, clinicians or decision makers?
Yes. Those populations are part of the same graph, so they behave as filters rather than as separate products you buy alongside. Developers can be narrowed further by the languages, topics and public repository activity behind their profile — evidence rather than a self-declared skill.
We already bought a bulk file. Is Search still useful?
Usually more useful, not less. Teams hold the bulk cut for the joins they repeat and use Search live over the same graph for the questions the file cannot answer yet.
Can we offer the search to our own users?
Yes — platforms run it inside their own product under their own brand. Tell us what you are building and we will scope it with you.
Bring the description
Tell us who you are trying to find.
Fifteen minutes, the search you actually need to run, and the people the graph returns for it.