People Search API: Find Decision-Makers at Any Company

A people search API takes a company domain and returns named professionals who work there, filtered by seniority, department or job title, usually with a work email and a LinkedIn link where the provider has them. You call it when you know the account but not the person, and you pay for what comes back.

What the call actually does

The mental model is a database query over a store of professional records. You do not describe a person; you describe a slice of a company. “Give me the senior people in engineering at this domain” is a typical question, and the service answers with a list rather than a single record.

That is the main difference from the neighbouring endpoints. An email finder starts with a name and returns an address. Person enrichment starts with an email or profile and returns the person behind it. Search starts with an account and returns people. Many workflows chain them: search to discover contacts, enrichment to complete a half-filled lead.

The BusinessMCP request, field by field

BusinessMCP documents its search endpoint publicly on the People Data API page. It is a POST to /api/hub/v1/people/search, also exposed to agents as the MCP tool people_search. The page lists these inputs.

Field	Required	Limits stated on the page
domain	Yes	Up to 253 characters
seniority	No	String array, 0 to 6 items
department	No	Up to 40 characters
title_contains	No	Up to 60 characters
limit	No	Default and maximum not stated

Authentication is a bearer token, and the examples read the key from an environment variable called BUSINESSMCP_API_KEY. Bearer tokens are a standard HTTP mechanism described in RFC 6750, which is a useful reminder to keep the key out of client-side code and logs.

The page does not reproduce the response schema; it links to the developer documentation for that. We therefore avoid describing exact response keys here. What it does say is that results are named decision-makers with a work email and LinkedIn where known, which implies some records will have neither.

Key takeaway: treat a search response as a list of candidates, not a finished contact list. Fields marked “where known” will be empty for some people, and your code should handle that without breaking.

How the pricing behaves

Search is priced at $0.08 per item. The unit matters: you are billed per person returned, not per call. A query that returns four people costs a different amount from one that returns twenty, and a query that returns nobody is not charged, because the page says all people calls are charged only when a result is found.

For budgeting, that means the filter design is a cost lever. A narrow query such as one seniority tier in one department costs less and produces a shorter, more relevant list. A broad query on a large account can produce a long list you did not need. The pricing breakdown works through a few scenarios.

Filters worth using

Most mistakes in people search come from asking too broadly. Three habits help.

1. Start with seniority and department together. A list of “everyone” at a mid-size company is rarely the goal. Ask for the buying group instead.
2. Use title_contains for precise roles. It is a substring match on the title field, so a short, distinctive word such as “security” or “procurement” will serve better than a full job title with qualifiers.
3. Exclude what you already own. The endpoint documented on the page has no stated deduplication against your CRM, so do that on your side before you pay for the same person twice in a later run.

Our walkthrough of finding decision-makers by company domain shows how to structure these queries into a repeatable process.

What search will not return

A search API is only as useful as its exclusions are clear. BusinessMCP is explicit that it never returns people located in the EU, EEA, UK or Switzerland, and it also excludes people placed in California, Texas, Vermont or Oregon, as well as US people who cannot be placed in a state. When a person’s own state is unknown, the page says the employer’s state is used. Opted-out people are removed from the store within about a day.

Two practical consequences follow. First, a company headquartered in a covered country may still return fewer people than you expect, because individuals are excluded by their own location. Second, an empty result does not mean nobody works there; it can mean everyone relevant is outside the covered regions or absent from the store. The page states no coverage or accuracy figures, so measure on your own accounts. The privacy article explains the reasoning behind regional exclusions.

Testing a search endpoint before you commit

A short test beats a long vendor call.

• Pick 30 to 50 accounts you know well, across sizes and countries.
• Run the same filters for each and record how many people come back.
• Hand-check a sample against what you know: are the titles current, are the right people present?
• Note how many accounts return nothing, and whether they cluster in a region.

If the result looks thin for your territory, say so early. BusinessMCP’s own comparison material describes its people coverage as business contacts in limited regions and says its store is smaller than the largest vendors’, which is the kind of candour you should look for in any provider. Its company-level API is the better fit if you only need account data with no individuals involved.

A worked budgeting example

Say you track 200 target accounts and want the top two security or engineering leaders at each. If the endpoint returns two people for 150 accounts and nobody for the other 50, you pay for 300 items at $0.08, which is $24.00, and nothing for the 50 empty accounts. That arithmetic is only an illustration, because the page does not state typical result counts. The useful lesson is that spend tracks results, so a sudden jump in your bill usually means a filter loosened, not that the vendor changed prices.

Plan a re-run schedule as well. People move jobs, and a list pulled in January is partly wrong by autumn. Rather than re-querying all 200 accounts monthly, re-query accounts where a deal is live or a trigger fired. If you are comparing vendors on this kind of workload, the BusinessMCP comparison of company data APIs lists per-record prices for several well-known providers with sources, and our own selection guide explains how to weigh them.

When search is the wrong tool

If you already hold a name, use the email finder. If you hold an email, use enrichment. If you need the same people for a whole target-account list every month, consider caching results and re-querying only accounts that changed, because per-item billing rewards restraint. And if your purpose falls under the prohibited uses on the provider’s page, which for BusinessMCP include credit, employment, insurance and housing decisions, do not use the endpoint at all.