Apollo Extension or Apollo API: Which One Does the Job You Have
One company call returned 66 fields including 271 technologies in 2.5 seconds. A person call returned a null title and a null email, and still billed.
Copy this line to your agent to enrich a company the way the extension would.
set up https://monid.ai/SKILL.md and use apollo /organizations/enrich with a domain
The Apollo extension puts a sidebar on a company's LinkedIn page and fills it with contacts. The API does the same lookups without a browser. On 2026-09-21 one company call returned sixty-six fields in two and a half seconds, including a list of two hundred and seventy-one technologies. A person call four days earlier returned thirty-five fields in which the job title and the email address were both null, and it billed anyway. Those two results are the whole choice. This guide runs through Monid, the OpenRouter for agent tools.
What does the Apollo extension actually do?
It reads the page you are on, matches it to Apollo's database, and shows you the record in a panel. Three things follow from "the page you are on".
It is driven by navigation, not by a list
You get data about whatever you are looking at. That is excellent when you are already researching one company and useless when you have a spreadsheet of four hundred domains, because a browser panel has no way to iterate.
It spends the same credits
A reveal is a reveal. Clicking "access email" in a sidebar and calling the enrich endpoint draw on the same allowance, so the extension is not a cheaper route to contacts, it is a different surface onto the same meter. The tier structure underneath, and the ratio between an email reveal and a phone reveal, is measured in the per-contact pricing guide.
It shows you a subset
A panel has to fit on a screen next to the page. Our API call returned sixty-six fields on one organization, which is not a sidebar's worth of information. Whatever the extension chooses to display, the rest is still in the record and you only see it through a call.
So the real question is not which is better
It is which shape your job has. One company at a time, by a person, while reading: extension. Many companies, by a program, on a schedule: calls. The measurements below are what the second option actually gives you.
📖 See also Apollo Email Finder API: Two Providers, One Mailbox, Two Owners
What does the API return that the extension does not?
Sixty-six fields for a company, and an honest answer about a person the panel would have shown as a blank.
The company call
apollo/organizations/enrich with a domain, 2.5 seconds:
{ "name": "Patagonia", "primary_domain": "patagonia.com",
"industry": "retail",
"estimated_num_employees": 4000,
"founded_year": 1973,
"annual_revenue": 1470000000,
"phone": "+1 800-638-6464",
"total_funding": null, "latest_funding_stage": null,
"keywords": ["product lifecycle extension", "environmental responsibility", …],
"technology_names": [".NET", "AB Tasty", "AI", "Act!", "Adobe", …] // 271 entries
}
Sixty-six keys. A revenue estimate, a headcount estimate, a founding year, a switchboard number, a positioning keyword list and a technology list, for one call in two and a half seconds. The funding fields came back null, which is correct for a privately held company that has not raised.
The person call, from four days earlier
apollo/people/match on a named executive at that same company, 7.2 seconds, thirty-five keys:
id present
organization_id present
country "United States"
title null
email null
email_status "unavailable"
linkedin_url null
seniority null
departments []
The base charge landed. That is not a fault: the endpoint's own pricing note says it bills the base when it can attach the name to a known company even with no email and no title, and that is precisely what happened.
Why this comparison is the useful one
The company side is where the API wins outright. A panel cannot show you 271 technologies and a revenue estimate at once, and it certainly cannot do it for four hundred domains overnight.
The person side is where the honesty shows. An email_status of unavailable is the endpoint telling you not to spend on a reveal. In a sidebar the same record is a greyed-out button, and the information that it will never resolve is not as legible.
And one parameter warning. The body form of people/match is rejected outright: identifiers must go in the query parameters. Invalid input: At least one person identifier is required is what you get for putting them in the body.
How do you replace the extension with calls?
Three steps, in this order, because the order is what keeps the bill down.
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. Enrich the company first
What it does. Gives you the firmographics, the technology list and the headcount before you spend anything on people.
The endpoints. apollo/organizations/enrich, per call, takes domain or linkedin_url.
monid run -p apollo -e /organizations/enrich --query '{"domain": "patagonia.com"}'
Why first. Company enrichment is one call per company. People are one call each plus reveals. Qualifying on the company field first means you never run the expensive step on a company you would have dropped.
Step 2. Match people without reveal flags
The endpoints. apollo/people/match, tiered, takes first_name, last_name and domain as query parameters.
monid run -p apollo -e /people/match \
--query '{"first_name":"…","last_name":"…","domain":"patagonia.com"}'
Read email_status before doing anything else. unavailable means stop.
Step 3. Reveal the class you will actually use
Set reveal_personal_emails only when you will send a personal email. Set reveal_phone_number only when a call is the plan, because that tier costs eight credits against one, and it charges only when a number is actually returned.
And inspect before you copy a request body
Our first search attempt used the parameter names from Apollo's own published search API and got a 400 naming them as unrecognised keys. Run monid inspect -p apollo -e /mixed_people/api_search and use what it prints, not what you remember.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to enrich these 200 company domains on apollo, keep the ones with more than 500 employees that use Salesforce, then match the VP Sales at each without any reveal flags and tell me how many have an available email.📖 See also Wire Up ICP Prospect Search with People Data Labs
Why are there 271 technologies on one company?
Because it is an accumulated list of everything ever detected, not a current stack, and two other sources on the same domain the same day prove it.
Three sources, one domain, 2026-09-21
apollo /organizations/enrich 271 technologies
hunterio /companies/find 18 technologies
api.strale.io tech-stack-detect 0 technologies
Fifteen of Hunter's eighteen also appear in Apollo's list. Hunter's three extras are BambooHR, Fabric and Microsoft Word.
What each number actually means
Zero is a live detector. It fetched the page, looked at HTTP headers and HTML patterns, and found nothing it recognised, which happens on a site behind a CDN that renders client side. On our own domain the same endpoint found two things, Amazon CloudFront from a response header and Nuxt.js from an HTML pattern, each with a confidence and an evidence string.
Eighteen is a curated database: a set somebody maintains with an opinion about what counts.
Two hundred and seventy-one is everything ever associated with the domain, and the list tells you so itself. "Adobe Fonts" appears twice. Members include "AI", "Air" and "Adobe", which are not technologies a stack can contain. Anything that touched the domain across years of crawls is in there.
How to use a list like that
Filter for specificity. Named products with versions or vendors are signals. One-word entries are noise. A rule as crude as "drop any entry shorter than four characters or matching a generic category word" removes most of the damage.
Use it for presence, never for absence. "Salesforce is in the list" is a weak positive. "Segment is not in the list" is worth nothing at all, because absence from an accumulated list means nobody ever detected it, not that it is not there.
Cross-check the one technology your play depends on. If your outbound hinges on a company running a specific tool, verify it with a live detector rather than trusting an entry in a list of 271. The two routes and what you give up choosing between them are the subject of the technographic comparison.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
apollo/organizations/enrich | Company record | domain or linkedin_url | 66 fields, revenue, headcount, 271 technologies | Qualifying before you spend on people | Per call |
apollo/people/match | Match a person, optional reveals | first_name, last_name, domain as query params | 35 fields, email_status | Testing existence cheaply | Tiered, base plus reveals |
apollo/mixed_people/api_search | People by filters | Inspect for the real param names | Person list | Building a list from filters | Per call |
hunterio/multi-domain-search | Population with existence flags | Department, seniority, size | Redacted rows with flags | Sizing before any spend | Free |
api.strale.io/x402/tech-stack-detect | Live technology detection | url | Named technologies with evidence | Verifying one technology claim | Per call |
Every row was verified with monid inspect on 2026-09-21. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The free row belongs in any comparison with Apollo, because sizing a population costs nothing there and Apollo charges a base per person.
When should you keep the extension?
Four cases, and they are ordinary.
A person is doing the research. Someone reading a company's page who wants the contacts in front of them is using an interface, correctly. No API makes that faster.
Your volume is a handful a day. Below a few dozen lookups, writing and maintaining an integration costs more than the clicking does.
You want the workflow, not the data. Sequences, task queues, CRM writeback and the rest of the platform sit around the extension. Per-call endpoints deliver records and none of that.
You need what only Apollo's own product offers. Saved searches, alerts, team sharing and the enrichment of your own CRM records are seat features. An API gives you fields, not a product.
And the disclosure: this is Monid's blog and we resell these endpoints. The advice here is to enrich the company first so you buy fewer person records, to read email_status before paying for a reveal, and to distrust a technology list we sell you unless the entry is specific. All three reduce what you spend with us.
Conclusion
The Apollo extension and the Apollo API are the same database through two surfaces, and the choice is decided by whether a person or a program is doing the looking. The company side of the API is genuinely strong: sixty-six fields in two and a half seconds, with a revenue estimate, a headcount, a switchboard number and a technology list. The person side is honest rather than generous: on a named executive it returned a null title, a null email and a status of unavailable, and it charged the base exactly as its documentation says it will.
What matters more than the surface is the order and the scepticism. Enrich the company before you touch a person, because one call per company is cheap and one call per person plus reveals is not. And treat the 271-entry technology list as presence evidence only, never absence, since a live detector found zero on the same domain and a curated database found eighteen, which is three answers to one question on one afternoon.
Free next step: run monid inspect -p apollo -e /people/match and read the pricing note about what happens on a partial match. It is the clearest sentence anyone in this category has written about their own billing. Start at monid.ai.
FAQ
Do the Chrome extension and the API share the same credits?
Yes. A reveal costs what a reveal costs regardless of whether a person clicked it in a sidebar or a program requested it, so the extension is not a way to get contacts more cheaply. What changes between the two is control rather than price: through the API you can match without any reveal flags set, read the email status, and decide per row whether the reveal is worth it, which a panel does not encourage. The tier structure that makes this worth thinking about, including the eight-to-one ratio between a mobile number and a personal email, is measured in the per-contact pricing guide.
Can you do bulk reveals without a browser?
Yes, and that is the main reason to use calls instead. A browser panel operates on the page in front of it, so a list of four hundred domains means four hundred page visits by a human. The endpoints take an identifier and return a record, so the same list is a loop. Do it in the order that keeps the bill sane: enrich each company once, drop the companies that fail your criteria, match people at the survivors without reveal flags, and reveal only the rows whose status says an address exists. That sequence turns four hundred companies into far fewer paid person lookups than a person clicking through would produce.
Why did the search endpoint reject parameters from Apollo's own docs?
Because a gateway normalises parameter names across providers, and the names it accepts are the ones its schema publishes rather than the ones in the upstream vendor's documentation. Our attempt with q_organization_domains and person_seniorities came back as a 400 listing them as unrecognised keys, at no charge, which is the good kind of failure. The fix is one command: run inspect on the endpoint and read the properties it actually declares. It is worth doing for any endpoint whose request body you are copying from memory or from a vendor page.
How much should you trust the revenue and employee numbers?
Treat them as bands rather than figures. Our call returned an estimated headcount of 4,000 and an annual revenue of 1,470,000,000 for a private company that publishes neither, so both are modelled. They are useful for segmentation, where being in the right order of magnitude is all that matters, and unsuitable for anything that looks like a financial claim. For comparison, a different provider's record on the same company the same week gave a headcount of 3,780 and a band of 1K-5K, which is the right way to read all of these numbers: consistent enough to sort by, not precise enough to quote.
Last updated September 2026.
