RocketReach Pricing vs Pay-per-Call Contact Lookups

Look up one person's contact record and see exactly what each part costs. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to match the CEO of Patagonia by name and company without any reveal flags, and tell me which fields came back, which came back empty and what the call cost.

One prompt runs a lookup and reports the bill. 1 min setup · 2-6 hrs saved.

You searched for RocketReach pricing because you want to know what a contact costs: per month, per lookup, per email. Contact database vendors often sell a monthly allowance by the seat, so the answer is a plan rather than a unit price. This guide shows the other model, a charge per call, with a live lookup we ran on 2026-10-16: what the match cost, what came back, what stayed empty and where the larger charges sit. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to pay per contact lookup instead of per seat?

Monid. Install it once, add a key, and your agent calls a people enrichment endpoint with a name and a company and gets a typed record back, with no seat to buy and no allowance to burn down before the month ends.

• Pay per call. A person match through Apollo costs $0.026 and a match through ContactOut costs $0.02 (Verified 2026-10-16 on the people enrichment tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
• One install, every API. The same key and balance call both providers and every other tool on Monid. Find the person on one, enrich on another, with one bill. Buying a dataset or calling an API explains the seat-versus-call split behind that choice.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the lookup is there whenever your agent needs one, on demand, with nothing to renew. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

The price is for the match. Revealing a work email or a mobile number is a separate, larger charge, which the next sections measure.

What does one contact lookup actually cost?

The base and the reveal

A match costs a base charge, and each class of contact you reveal adds its own. We ran one lookup on each provider on 2026-10-16 for the chief executive of Patagonia, a person whose role is public, and paid for exactly two calls.

The multiples come from monid inspect (Verified 2026-10-16). Apollo prices its tiers in credits where one credit equals the base charge, so a mobile number is 8 credits on top of the match. ContactOut lists the work email and phone rows as their own prices, and a work email found is 5 times the base while a phone found is 9 times. Both providers charge nothing when they cannot match the person.

Our two calls cost $0.046 together (Verified 2026-10-16): $0.026 for the Apollo match and $0.02 for the ContactOut match. Neither call asked for a reveal, so neither paid a reveal charge.

What that means per contact

That is the answer to a per-contact pricing question: a contact is not one price. It is a match, then a decision about which class of contact to see, and the decision moves the bill by a factor of five to nine.

📖 See also Apollo email finder API

How do you look up one contact and read the meter?

Send a name and a company, leave the reveal options off, and read what came back before you spend more. The meter is in the response for one of the two providers.

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

Read the price before the first call

monid inspect -p apollo -e /people/match

The pricing block spells out the base, each conditional tier, the flag that triggers it and whether the flag alone charges. It also says a no-match consumes nothing, which lets you try lookups without a cost on the misses.

Match first, with no reveal flags

monid run -p apollo -e /people/match \
  --query '{"first_name":"…","last_name":"…","domain":"example.com"}'

This endpoint takes its identifiers as query parameters, so the first name, last name and company domain go in --query and not in a body. Our call returned its first response with the status RUNNING and completed about five seconds after it was created, so a script has to poll the run id until the status is COMPLETED.

What came back for the Patagonia chief executive was a record with an id, a first and last name, a country, an employer id and a filled organization block (industry retail, about 4,000 employees, headquartered in Ventura). The fields that would make the person useful were empty: title was null, email was null, email_status was unavailable, linkedin_url was null and seniority was null. The record also carried match_confidence: "low". The call still billed one unit, $0.026 (Verified 2026-10-16), which is the documented rule that the base lands when the name attaches to a known company.

Try the other provider on the same person

monid run -p contactout -e /v1/people/enrich/work-email \
  -i '{"full_name":"…","company":["Patagonia"]}'

This endpoint takes a POST body, so it uses -i. The company field is an array of strings, and passing a plain string is rejected by the input schema. It answered in about a second with a full profile: the headline "Chief Executive Officer at Patagonia", the industry, seniority CXO, five experience entries, three education entries and a skills list. Every contact array (email, work_email, personal_email, phone) was empty, because we did not pass include. The top level reported its own consumption: work_email_units 0, phone_units 0, search_units 1. It billed $0.02 (Verified 2026-10-16).

The two lookups returned different halves of the same person. One described the employer and left the person blank. The other described the person and returned no contacts because we had asked for none. The meter on the second one, work_email_units and phone_units in the body, is the useful part: it tells you per response what you were charged for.

📖 See also Hunter.io domain search vs email finder

Why is a phone number the expensive field?

The structure

Because both providers price it as its own charge, well above the match, and charge it only when a number is actually returned. On Apollo, the mobile phone tier is 8 credits on top of the base, which at $0.026 is eight times the match. On ContactOut, a phone found is 9 times the base (Verified 2026-10-16 with monid inspect).

Three things follow from that structure.

The ratio is the design constraint. One mobile number costs as much as eight or nine matches. A pipeline that asks for phones on every row by default has multiplied its bill by a factor nobody chose. Set reveal_phone_number only where a call is the plan.

Pay on delivery is the fair form. Both providers state that the phone tier bills only when a number is found. On Apollo the flag alone never charges, so a thin list costs nothing extra on the misses. The matching cost is still paid on every row.

Phone is slower too. Apollo produces mobile numbers asynchronously, so a run with reveal_phone_number stays RUNNING for several minutes. We did not run it today, so the timing here is what monid inspect says, not what we measured.

A free population search tells you how many people on a list have a phone at all before you spend on it. The B2B prospecting guide runs that free search first and reveals only the rows that pass.

Can you build contact lookup yourself?

Not in any way that gets you the contact data. A scraper can read a public profile page, but the work emails and phone numbers that vendors sell come from their own databases, and that is what the per-call price buys. Building it yourself means collecting, verifying and refreshing that data, which is a business and not a script.

What you can do yourself is the cheap part: guess an address pattern from a name and a domain, and verify it with an email verification call. That works for small lists and misses on any company that does not use a predictable pattern. The data route is the Monid route: the endpoint is maintained for you, the output is typed JSON with a unit counter, and you pay for the lookups you run.

Free tiers and free trials of seat products exist, and they suit a person trying a tool by hand. They are not an API for an agent or a loop.

What goes wrong when you pay per contact?

Four things show up when you read the output of more than one lookup. All four come from the 2026-10-16 runs.

Why can you pay for a match and get nothing usable?

Because the match is a product. The Apollo call billed one unit for a record with an id, a country and an employer, and an empty title and email. The inspect note says the base is billed when the name attaches to a known company, even with no email or title. Treat email_status: "unavailable" and match_confidence: "low" as a stop signal before any reveal.

Why is a no-match free and a partial match not?

Because "found nothing" and "found something thin" are different events and only one bills. If the provider cannot find the person, you pay nothing. If it finds a record, you pay the base. The failure that costs money is the near miss, so design for it: match without reveal flags, filter, then reveal.

Why do two providers disagree about the same person?

Because they hold different data. For the same executive, one returned an empty title and the other returned the exact headline. Neither is a malfunction. If a field matters, call both on a sample and compare before you pick one for a list. Reverse email lookup shows the same mismatch from the email side.

Why does a field exist and still hold no data?

Because the contact arrays are always present in the ContactOut response and are empty unless you ask for them. work_email, personal_email and phone came back as [] here because include was not passed. An empty array in a billed response is not a failed call; it is the unrequested reveal.

Which endpoint should I use for which job?

Both rows were run on 2026-10-16. For wider coverage of the prospecting endpoints, the people enrichment tools page lists the rest, and current prices for every endpoint are on monid.ai/tools.

When is a seat cheaper than per-call?

Your team browses. Reps who open a tool, search, read a profile and decide are using an interface, and a seat with a monthly allowance is the right shape. An API does not make a person faster at reading a profile.

Your volume is steady and high. A fixed allowance can beat variable per-call spend once you reliably use most of it. The way to find the crossover is to run a month of real lookups per call and compare, which costs the base charge on each match.

You need the interface. Saved searches, list building, browser extensions and CRM sync are seat features, and per-call endpoints do not carry them. Apollo's extension or API covers that fork.

You cannot tolerate variance. A finance team that needs one number a month will prefer a seat even at a worse unit rate. That is a legitimate reason.

And the disclosure: we resell the endpoints measured here, and RocketReach is not one of them. We describe vendors like it only in general terms. The most useful finding in this post is that a match can bill for a record with nothing usable in it, and the habit that follows, match first and reveal second, means buying fewer reveals from us.

Conclusion

A contact does not have one price. A match has a price, and each class of contact you reveal adds its own, five to nine times the base on the ContactOut endpoint and eight credits on the Apollo one. The cheapest way to learn what your list costs is to pay for matches only: through Monid a match is $0.026 on Apollo or $0.02 on ContactOut (Verified 2026-10-16), with one key, no minimum top-up and the lookup ready inside your agent.

Two things matter more than the provider. Match first without reveal flags and read email_status and match_confidence before you spend on a reveal. And log the unit counters the response returns, because a per-class consumption count on every response is a better cost model than any plan page.

How we estimated the time saved: reading three or four vendors' pricing pages and working out what a contact costs on each is roughly 1 to 3 hours, and building a small test harness to match a sample and tally the units is another 1 to 3 hours. That is 2 to 6 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p apollo -e /people/match, read the pricing block, then make one match with no reveal flags on a person you know. Start at monid.ai.

FAQ

Published September 2026.