B2B Prospecting Tool by API: The List Is Free, the Name Is the Bill
One free call returned 100 sales leaders at 47 companies with names redacted. Revealing who they are is the paid step. How three prospecting routes bill.
Copy this line to your agent to build a prospect list for one ICP.
set up https://monid.ai/SKILL.md and use hunterio /multi-domain-search for a department and seniority
On 2026-09-16 we described one ideal customer, sales leadership at US companies of 51 to 200 people, and asked three prospecting endpoints for it. The first returned 100 people at 47 companies, 68 of them decision makers, for nothing, with every name shortened to an initial. The second returned 24 complete profiles with a flag saying 13 had a work email and an empty array where the email would be. The third returned ten LinkedIn profiles for one page charge. None of them handed us a contact. All of them told us exactly where the bill would land when we asked for one. This guide runs through Monid, the OpenRouter for agent tools.
What is a B2B prospecting tool, in API terms?
Three calls in sequence: a search that returns people matching a filter, a reveal that turns a person into a contact, and a first touch that uses the contact. Most tools bundle them into one UI. The API pulls them apart, and the seams are where the cost sits.
The search
You describe a population, not a person. Department, seniority, company size, geography, technology. What comes back is a page of rows, each a person you did not know existed, with enough attached to decide whether to spend on them.
The reveal
You hand back one row and get an address or a number. This is the step every provider prices, because it is the step that has value, and it is why the search is cheap or free: the search is the menu.
The first touch
An email, a call, a message. This is a different category of endpoint from the two above, it is priced per message, and it is the one where the law changes what you are allowed to do.
Why the split matters
A tool that shows you a contact for every row on the first screen has already spent your money on people you had not chosen. An API that returns existence flags and a reveal token lets you choose first. On 2026-09-16 the free search told us seven of a hundred rows had a phone number at all, which is a fact worth knowing before paying for any phone reveal.
📖 See also People Data Labs, Apollo, ZoomInfo: Which Should You Actually Buy?
Why is the list free and the name expensive?
Because the list is the provider's advertisement for the reveal, and three providers priced the same population three different ways to prove it.
Route one: free rows, paid reveal
hunterio/multi-domain-search with department sales, seniority executive, headcount 51-200, location US, verification valid:
{
"name": "Alex W.",
"position": "Vice President of Sales",
"department": "sales", "seniority": "executive",
"type": "personal", "decision_maker": true,
"domain": "sharethis.com", "company_name": "sharethis",
"full_name_exists": true, "phone_number_exists": false, "linkedin_exists": true,
"verification": { "status": "valid" },
"reveal_handle": "Cc_WSKjEKBv-_N9HPDL5pKB91CVSgl9y…"
}
One hundred rows, meta.results: 38860, a cursor for the next page, and the call cost nothing. The name is an initial. The address is behind reveal_handle, a 125-character token you pass to a paid endpoint. Across the hundred: 47 companies, 68 decision makers, 90 with a LinkedIn profile, 7 with a phone number, all 100 with a verified-status address waiting behind the token.
Route two: full profile, empty contact array
contactout/v1/people/search/work-email with job titles VP Sales and Head of Sales, US, sales function: total_results: 112863, 24 profiles on the first page, billed per profile.
Each profile carried experience history, education, skills, certifications, follower count and an updated_at between 2026-08-29 and 2026-09-08. Each also carried this:
{ "contact_availability": { "work_email": true, "personal_email": true, "phone": true },
"contact_info": { "emails": [], "work_emails": [], "phones": [] } }
Thirteen of 24 said a work email was available. Twenty-three said a personal email was. Nineteen said a phone was. Every contact array was empty. Availability is a flag; the contact is a further reveal on a separate tier. The search charged per profile for the flag.
Route three: per page, thin rows
apify/harvestapi/linkedin-profile-search in Short mode, ten profiles, one search page, 7.5 seconds. Fields: id, LinkedIn URL, first and last name, open-profile and premium flags, current positions, location. The headline field was empty on every row in Short mode, and email is only offered at the "Full + email search" mode, which adds a per-profile charge on top of the per-page one.
What the three have in common
| Search billed | What the search returns | Where the contact is | |
|---|---|---|---|
hunterio/multi-domain-search | Free | Redacted name, role, flags, verification | Behind reveal_handle, paid |
contactout/…/work-email | Per profile | Full profile, availability flags | Behind a reveal tier, paid |
apify/harvestapi/linkedin-profile-search | Per page | Identity, positions, location | Only in the top mode, per profile |
Three units for the same population. The pattern is the same in every row: the list identifies, the reveal delivers, and the reveal is the product. This is the same shape as the email finder that returned a score of 16 in the Hunter.io guide: the provider is honest about what it has and charges when it hands it over.
How do you build a B2B lead list through one key?
Three steps, and the first one is free, which changes the order you would otherwise use.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Search wide, for free
What it does. Returns the population with existence flags, so you can size the job before spending.
The endpoints. hunterio/multi-domain-search, free per call, takes department, seniority, headcount, location, technology and more.
The call.
monid run -p hunterio -e /multi-domain-search \
--query '{"department":"sales","seniority":"executive","headcount":"51-200","location":"US","verification_status":"valid","required_field":"full_name,position"}'
What comes back. 100 rows per page with meta.results telling you the total (38,860 on ours) and next_search_after for paging. Read the flags before anything else: decision_maker, phone_number_exists, linkedin_exists.
What it costs. Nothing. Page the whole population if you want; the bill starts at the reveal.
Step 2. Reveal only the rows you chose
What it does. Turns a redacted row into a contact.
The endpoints. The reveal endpoint on the same provider, passing reveal_handle; or apollo/people/match with the name and domain if you prefer a second provider's view.
What comes back. An address with a verification status, which on a catchall domain means what the Apollo email finder guide says it means.
What it costs. Per reveal. Sixty-eight decision makers is sixty-eight reveals, not a hundred, because you filtered on a free flag first.
Step 3. Cross-check the ones you will actually contact
What it does. Catches the provider disagreement before it reaches a send.
The endpoints. contactout/v1/people/search/work-email by name and company for a second read, or hunterio/combined/find by the address you revealed.
What comes back. Either agreement, or the kind of two-owners-one-mailbox result measured in the reverse email lookup guide, which is the most valuable row in the table.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to search for sales leaders at US companies with 51 to 200 people, keep only decision makers with a LinkedIn profile, tell me how many have a phone, and reveal the first twenty.📖 See also Wire Up ICP Prospect Search with People Data Labs
How does B2B SMS outreach fit after the list?
As a per-message endpoint that sends from a number you own, and as the step with the most rules attached.
The endpoint
saperly/send-messages takes three fields: fromNumberId, the id of a phone number you have provisioned, to in E.164 format, and body of 1 to 1,600 characters, with long bodies split into multiple messages. It is billed per call, and the schema notes that opted-out recipients are handled rather than silently sent to.
What we did not do
We did not send one. Sending an SMS to a real person to generate a screenshot is not evidence worth having, so this section describes the schema and says so. Everything above it in this article was measured; this step was read.
Why it belongs at the end
Seven of a hundred rows in our free search had a phone number at all. That is the population SMS can reach, and it was knowable before any reveal. A prospecting pipeline that plans SMS as the primary channel and discovers the seven percent after paying for a hundred reveals has done the steps in the wrong order.
The order that works
Free search for flags, reveal the decision makers, email first because that is where the addresses are, and SMS for the small subset where a phone exists and the recipient has not opted out. The wider outreach tooling comparison, including the seat-based platforms that bundle sequencing, is in the LinkedIn outreach tools guide.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
hunterio/multi-domain-search | People matching a company and role filter | Department, seniority, headcount, location | 100 redacted rows per page with flags | Sizing the population first | Free per call |
contactout/v1/people/search/work-email | Full profiles by title and function | Title arrays, seniority, location, skills | 25 profiles per page with availability flags | Rich profile before reveal | Per profile |
apify/harvestapi/linkedin-profile-search | LinkedIn profile search | Query, titles, companies, locations | Profiles per page | LinkedIn-native filters | Per search page, plus per profile in Full modes |
apollo/mixed_people/api_search | People by title and company filters | Filters | Person list | A fourth reading of the same ICP | Per call |
saperly/send-messages | Send an SMS from your number | fromNumberId, to, body | Delivery record | The first touch, for the rows with a phone | Per call |
Every row was verified with monid inspect on 2026-09-16. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The first row is free and the reason to start there. A free search that returns existence flags lets you decide which reveals to buy, which is the whole economic advantage of pulling the tool apart into calls.
When is a prospecting API the wrong tool?
Four cases.
Your team lives in a sequencing UI. Reps who open a tool every morning want the list, the reveal and the send in one screen with a task queue. That is a seat-based product, and an API does not replace it; it feeds it. Buy the platform, and consider the API as the thing that fills it.
You need the population, not the people. If the question is "how many sales leaders are there at US companies of this size", the free search answered it: 38,860. Stop there. Revealing any of them is a different job.
You want to text people who did not ask. SMS outreach to business contacts is regulated differently by country and carrier, consent rules apply, and the endpoint's opt-out handling is a floor, not a defence. Get a legal read before the first campaign, and treat the seven-percent phone coverage as a reason to make SMS the exception rather than the plan.
You are filtering on a field you cannot see. Our first free search returned a 400: industry must be one or more integer industry codes within 0..32767. The filter exists, the codes are not in the schema, and a word does not work. Dropping the filter was the fix; knowing the codes would have been better, and until they are exposed, filter on the fields that take words.
And the disclosure: this is Monid's blog and we resell all five endpoints. The recommendation here is to run the free one first and buy fewer reveals, which is a recommendation to spend less with us.
Conclusion
A B2B prospecting tool is three API calls wearing one interface, and the API shows you what the interface hides: the list is free or nearly free, the name is the bill, and the first touch is a separate product with rules attached. On one afternoon three providers returned the same population as a hundred free redacted rows, twenty-four paid profiles with empty contact arrays, and ten profiles per page, and every one of them put the contact behind a reveal.
What matters more than the provider is the order. Search for flags first, because phone_number_exists on seven of a hundred rows is the fact that should decide your channel before you spend on a single reveal. Reveal the decision makers, not the population. Cross-check the ones you will send to. And read the flag fields, because a contact_availability: true next to an empty contact_info array is the provider telling you plainly what the next charge is for.
Free next step: run monid run -p hunterio -e /multi-domain-search with your own ICP filters and read meta.results and the flag counts. It costs nothing, and it tells you the size of the job and the reach of each channel before you pay for a name. Start at monid.ai.
FAQ
Has anyone used People Data Labs for customer prospecting?
Yes, and it belongs on the same three-step shape as everything in this article: PDL's person search is the population step, billed per record returned, and its enrich call is the reveal, billed per call. The difference from the free-search route measured here is that PDL charges for the search itself, so the filter is also the budget and a loose filter is an expensive one. The comparison across PDL, Apollo and ZoomInfo, including which is a database and which is a seat, is in the provider comparison.
How do you manage a prospect database in the 80k to 120k range?
By storing the flags and the cursor, not the reveals. A population that size is a few hundred pages of a free search, and the free rows carry decision-maker status, channel existence flags and a verification status, which is enough to segment and prioritise the whole set without paying for a single contact. Reveal in cohorts as campaigns need them, store the provider and the date on every revealed row, and re-run the free search monthly to see who moved, because the updated_at on a paid profile was up to three weeks old on our sample and a free re-search is how you find that out.
Is B2B SMS outreach legal?
It depends on the country, the carrier and whether the recipient consented, and none of those is settled by an API accepting the request. In the United States, business-to-business texting sits under rules that differ from consumer marketing but still involve consent and opt-out obligations; in much of Europe it requires prior consent outright. The endpoint's opt-out handling is a compliance floor, not a defence. Treat SMS as a channel for contacts who have engaged, plan it for the small subset with a phone on file, and get a legal read before the first campaign.
Why did the industry filter reject the word Software?
Because the field takes integer industry codes, and the error said so: industry must be one or more integer industry codes within 0..32767. The codes are not in the endpoint's schema, so the filter is usable only if you already know the provider's taxonomy. The practical answer is to filter on the fields that take words, department, seniority, headcount, location, and to narrow by company afterward, which is what our retry did. It is also a reminder that a 400 naming the constraint is the good kind of failure; an endpoint that accepted "Software" and silently matched nothing would have been worse.
Last updated September 2026.
