B2B Data API and MCP: Leads, Employees, Emails and Phones From One Key

A b2b data api lets your software ask for business contact data and get structured JSON back: who works at a company, what they do, what their work email is, and who is behind a phone number. NeuralVerge exposes these lookups as separate sources on one account and one key, reached over REST or MCP. The catch is that each lookup starts from a different input, so most of this guide is about what to hand each one.

The short version

• —What it is. Four jobs on one key: find people, map a company's staff, resolve an email, resolve a phone. Each is its own lookup with its own price, so you run only the steps a record needs.
• —The thing to get right first. Every source needs a different starting point: filters, a company page, a name plus a domain, an email, a profile URL or a phone number. The table below lists them all.
• —No source turns a name into a phone number. Phone lookups go from a number to a person. For a named person, email enrichment returns alternate phones where they exist.
• —What it costs. Points, at one dollar per thousand on the plan rates on the pricing page. People search is 100 points per block of 25 results, an email found is 10 points, a validation is 1 point, and lookups that find nothing are mostly free.
• —Who it is for. Teams building outbound, recruiting or lead-routing pipelines in code or through an AI agent, rather than a person clicking through a sales tool.

What a B2B data API covers

The phrase gets used for several different products, so it helps to say what we mean. Here we mean four jobs that usually happen in sequence:

1. —Find people. Search for the individuals who hold a role, by title, seniority, function, company and location.
2. —Map a company. List the people who work at specific named companies.
3. —Get the email. Work out a person's work address, or work out who owns an address you already hold.
4. —Get the phone. Identify who is behind a number, or interrogate the number itself.

B2B data API vs. a sales-intelligence seat

A sales-intelligence tool gives a person a login, a search box and an export limit. A data API is built for code: the same filters become request parameters and results come back as JSON. If a human picks leads in a browser, a seat may fit; if a script or agent picks them, an API fits better.

B2B data API vs. an enrichment-only API

Pure enrichment starts from something you already have, an email or a domain, and fills in the rest. That is half the workflow, because someone has to decide whom to look up. NeuralVerge covers both ends: search to discover people and enrichment to complete their records. The email enrichment article covers the second half in depth.

What each source needs as input

This is where most of the confusion comes from. Each source expects a specific starting point, and the output of one is rarely the exact input of the next.

Starting from a role or a company

Nothing to look up yet, only a target. Leads search and LinkedIn people search take filters (title, seniority, company, location and more) and return matching people. LinkedIn company employee takes one or more company page URLs plus the same people filters and returns staff at those companies. LinkedIn company search takes a query and returns companies.

Starting from a name

You have a person and an employer. Two sources fit, and they return different things:

• —Email finder takes a first name, a last name and a company domain, and returns the work email with a confidence rating.
• —LinkedIn profile by name and domain takes a full name plus a company name or domain, and returns the matching profile with headline, company and location.

A name alone is not enough for either.

Starting from an email address

Email enrichment takes one address and returns the person behind it: names, current company and position, location, alternate emails and phones, and linked profiles where they exist. Email validation takes the same input but answers a different question, whether the address is deliverable. Neither one finds an email; both start from one.

Starting from a profile URL

The LinkedIn people profile source takes a profile URL and returns the professional record. LinkedIn people profile plus email takes a full profile URL and adds the email address where available.

Starting from a phone number

Phone enrichment takes a number in international format and returns the resolved person plus the network operator. For US numbers there is a separate, more expensive source that returns validity, carrier, line type, activity signals and owner records. These sources start from a number. They do not produce one.

How the steps chain

People search returns names, profile URLs, headlines, current company and location, and the source page states that it does not return an email. The sample response shows a company name, not a domain, so before email finder you need the company's domain from your own data. Two routes get from a search result to an email:

1. —Name plus domain. Pass the first name, last name and the company's domain to email finder.
2. —Profile URL. Pass the profile URL from the search to the profile-plus-email source.

Either result can then go through email validation before it reaches your sending domain. Each response also carries a session_id, so a record in your CRM can be traced back to the call that produced it.

Every source, its input and its price

The table lists leads search, the LinkedIn people and company sources and the enrichment entries, from the source pages and the leads search tool description, counted at the time of writing. The tool names are the MCP names.

A real request and response

Here is a real request and a real captured response for the discovery step. The request is the call shown on the people-search source page, filtering for senior revenue-operations people:

curl -X POST https://api.neuralverge.ai/functions/v1/run-linkedin-people-search \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "searchQuery": "head of revenue operations",
    "currentJobTitleFilter": ["Head of Revenue Operations"],
    "seniorityLevelFilter": ["Director"],
    "locations": ["United States"],
    "maxResults": 25
  }'

The response below is the sample captured for the source page, from a different run (a full-mode search for recruiters at OpenAI in Amsterdam), so its echoed parameters do not match the request above. The items array is shortened and the profile shown is a placeholder, not a real person:

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "verification_type": "data_source",
  "kind": "linkedin_people_search",
  "scraperMode": "full",
  "autoQuerySegmentation": false,
  "maxItems": 3,
  "startPage": 2,
  "locations": [
    "Amsterdam"
  ],
  "profileScraperMode": "Full",
  "recentlyChangedJobs": false,
  "recentlyPostedOnLinkedIn": false,
  "searchQuery": "OpenAI recruiter",
  "currentCompanies": [
    "OpenAI"
  ],
  "currentJobTitles": [
    "Recruiter"
  ],
  "human": "# LinkedIn people search\n\n- **Results returned:** 3\n\n### Jane Doe\n\n- **Profile URL:** https://www.linkedin.com/in/jane-doe/\n- **First name:** Jane\n- **Last name:** Doe\n- **Title:** Recruiter\n- **Company:** OpenAI\n- **Location:** Amsterdam\n- **Summary:** Technical recruiting across research and engineering roles.",
  "machine": {
    "total_items": 3,
    "first_item": {
      "firstName": "Jane",
      "lastName": "Doe",
      "profileUrl": "https://www.linkedin.com/in/jane-doe/",
      "headline": "Recruiter at OpenAI",
      "currentCompany": "OpenAI",
      "location": "Amsterdam"
    },
    "items": [
      {
        "firstName": "Jane",
        "lastName": "Doe",
        "profileUrl": "https://www.linkedin.com/in/jane-doe/"
      }
    ]
  },
  "points_per_25_results": 100,
  "points_per_profile": 5,
  "total_points": 115
}

Four things in that response are worth reading closely:

• —human and machine. The same result comes back twice, once as readable text for a person or a language model and once as fields for code. Use whichever your consumer needs and ignore the other.
• —points_per_25_results, points_per_profile and total_points. The bill is in the response. In this full-mode run it is 100 for the block plus 3 profiles at 5 points each, so 115. You can reconcile any run against it.
• —machine.first_item and machine.items. The first item carries the headline, company and location, while the entries in items shown in the sample carry name and profile URL. Check the live response for the fields you depend on rather than assuming every entry has the same shape.

The people-search response does not contain an email address, so the next step is a name plus a company domain. This is the machine block from the real email-finder sample, which resolved a work address for a well-known executive:

{
  "firstName": "Sam",
  "lastName": "Altman",
  "domain": "openai.com",
  "found": true,
  "email": "sam@openai.com",
  "confidence": "high",
  "provider": "enrich.so",
  "message": null
}

That call cost 10 points. Branch on found, not on whether email is empty, because a miss is returned as a normal response and is not billed.

REST and MCP

REST is a plain HTTPS POST with a bearer key, as in the example above. It suits scheduled jobs, backend services and anything that already speaks HTTP. MCP, the Model Context Protocol, suits an AI assistant or agent that should choose lookups itself. The same people-search lookup is the tool run_linkedin_people_search with the same arguments, and the email finder is run_email_finder. REST paths keep hyphens, as in run-linkedin-people-search; MCP tool names use underscores. The MCP setup guide covers connecting a client, and the documentation lists the parameters.

An agent may loop where a person would stop. Tell it which input it holds (a name and a domain means the email finder, an address means email enrichment, a number means phone enrichment), give it a points budget, set maxResults in the tool arguments, and have it log the total_points from each response.

Cost and limits

Every lookup is priced in points, and the points in a plan are the same whichever source spends them. The pricing page lists the plans and what they include. At the plan rates on that page one thousand points is one dollar, which is how the per-source dollar figures here are derived.

A worked budget

Take Acme Oy, an illustrative Finnish software company that wants a list of 25 revenue-operations directors in the United States with work emails. These are the maximum charges if every step succeeds, assuming you already hold each person's company domain, so treat them as a ceiling and not a forecast:

• —People search, one block of 25 results: 100 points.
• —Email finder for each of the 25 people: at most 250 points, and fewer if some do not resolve, since misses are free.
• —Email validation of each address found: at most 25 points.

That is at most 375 points, or about $0.38 at the plan rates, for a validated list. How many of the 25 actually resolve is something we have not measured for you, and the source pages do not claim a rate, so run a small batch on your own segment before you extrapolate.

Filters and mode move that number most. The people-search page warns that a search with no filters and no result cap is the fastest way to spend points badly, so set maxResults and a narrowing filter. Full mode adds a per-profile charge, so use it only when you need the extra fields.

Limits worth knowing

• —Results are a sample, not a census. The company-employee page says to treat results as a well-filtered sample of an organisation, not as its full staff list.
• —Titles are self-reported. Results reflect what people publish about themselves, including titles they gave themselves. Filter vocabularies are the platform's own, so a seniority or function label may not map onto yours.
• —Hit rates vary. Small companies and generic domains are the hardest for email finding. Personal addresses and numbers resolve less often than work ones, so a miss on a personal contact is expected and does not mean the lookup is broken.
• —You are the data controller for how you use it. These sources return personal data. Use it for legitimate business purposes under your own lawful basis, honour deletion and opt-out requests, and read the acceptable use policy for what is out of bounds.

How to decide

Run this checklist against any provider, including us:

• —What do you start with? If it is a role or a company, you need search. If it is a name and an employer, email finder. If it is an address, email enrichment. If it is a number, phone enrichment. A provider that makes you guess which input fits will cost you time.
• —What does a miss cost? Here, email finder, email enrichment and phone enrichment only charge on a match, and people search does not bill a search that matches nothing. Check the same for any alternative.
• —How are results produced? Look for whether data is resolved at request time or served from a stored list, since that decides how stale a record can be.
• —Can you trace a record back? A session identifier on every response is what lets you answer where a field came from.
• —Is the price predictable at your volume? Work out the ceiling for a batch like the Acme Oy example, then confirm it on a small real run.

Use cases that fit well:

• —Outbound prospecting. Search for a role across a defined set of accounts, find work emails for the matches, validate them before they reach your sending domain.
• —Account mapping. For a target account, list the people in the relevant function so you reach the buying committee and not a single contact.
• —Recruiting and sourcing. Filter by function, seniority and years of experience to build a shortlist, then resolve contact details for the people worth approaching.
• —Inbound lead enrichment. A signup arrives with only an email address. Email enrichment tells you who they are and where they work, so routing and scoring can use a real company and role.

Run the cheap, narrowing steps first, and complete only the records that survive.

Frequently asked questions

What is a B2B data API?

A B2B data API is a programmatic way to ask for business contact and company data: who works at a company, what their role is, what their work email is, and which person sits behind a phone number. Instead of exporting from a sales tool, your code or your AI agent sends a request and gets structured JSON back.

What input does each B2B lookup need?

It depends on the source. People search and leads search take filters such as title, seniority, company and location. LinkedIn company employee takes company page URLs. Email finder takes a first name, a last name and a company domain. Email enrichment and email validation take an email address. Phone enrichment takes a phone number in international format. The profile sources take a profile URL, or a full name plus a company name or domain.

Can I find an email address if I only know a name and a company?

Yes. The email finder takes a first name, a last name and a company domain and returns the work address with a confidence rating. It costs 10 points per address found, and a lookup that finds nothing is not billed. Not every person resolves, and small companies are the hardest.

Does phone enrichment find a number from a name?

No. Phone enrichment works in the other direction: you give it a number in international format and it returns the person behind it, plus the network operator. To get a number for a named person, start from email enrichment, which returns alternate phone numbers where they exist, and treat a missing number as normal.

How much does a lead list cost?

It depends on the filters and on how many steps you run. People search is 100 points per block of 25 results, plus 5 points per profile in full mode. Each email found is 10 points and each validation is 1 point. Points are included in monthly plans, and the pricing page lists the plans.

Is the data stored in a database that goes stale?

The source pages describe people search as searched at request time rather than served from a stored list. That means a result reflects what is published when you ask, including titles people gave themselves, and it can still be incomplete or out of date for an individual.

Can an AI agent call these lookups directly over MCP?

Yes. Each source is available over REST and as an MCP tool, with the same arguments. The REST path keeps hyphens and the MCP tool name uses underscores, so an agent can call any of these sources directly.