You cannot buy API access to Apollo.io with a credit card. The most important detail is buried on the pricing page in one line: "For more advanced or custom integrations, API access is available on Custom plans." If you are on a standard plan, the API is not included.
This explains why most search results are useless. UpLead's guide from 2024 never mentions this. ZoomInfo reviews skip it. Python documentation lists endpoints but ignores access. To make it worse, searching "apollo api" often leads to a completely different GraphQL tooling company. The few guides that actually cover Apollo.io skim past the one thing every buyer needs to check first.
This guide fixes that. I pulled Apollo's own pricing and developer pages, then read the threads its buyers post on r/UseApolloIo, r/Coldemailing and r/SalesOperations. I will cover how access actually works, what the endpoints do, the tier costs, what real users report getting back, and how people scrape Apollo when the API is out of reach. Where Apollo's claims and its users disagree, I show you both.
What is the Apollo.io API?
Apollo.io is a sales intelligence and engagement platform, which is essentially a 270M+ contact database wrapped in outreach tools. The API is the programmatic door to that data. You can search for people and companies, manage your Apollo workspace, or pull enriched records directly into your own product.
The core endpoints are simple. Use people search for prospects and organization search for companies. Contact and account endpoints handle the records inside your account. It is a standard REST API, JSON in and JSON out.
It is also the cheapest legal way to move Apollo data at scale, which is why the access tier is the only thing that really matters.
How do you get access to the Apollo.io API?
This is the part most guides ignore. Apollo's pricing page, checked November 2026, lists four plans: Free, Basic, Professional, and Organization. Basic is $49 per user per month billed annually, Professional is $79, and Organization is $119 with a 3-user minimum. Not one of them includes the API.
The API only exists on Custom plans. You cannot buy it from the pricing page. You have to talk to sales and negotiate your access, rate limits, and credit allowances. Apollo says it plainly: "For more advanced or custom integrations, API access is available on Custom plans."
Two other constraints shape how this works. First, every seat on an account must be on the same plan. You cannot buy one API-enabled seat and run the rest on Basic. Second, record selection limits cap how many records you can select in one action, with higher tiers getting higher or no limits.
There is no self-serve path to test the API cheaply before committing. This is the first thing you must verify with Apollo sales before you plan anything around this API.
What can the Apollo.io API do, and what does it cost?
Most people use the API for three things. Search pulls prospects from the database using filters. Enrichment adds contact data to records you already own. Management syncs contacts and accounts within your Apollo workspace.
A search request looks like this against the people search endpoint:
curl -X POST "https://api.apollo.io/v1/people/search" \
-H "Content-Type: application/json" \
-H "X-Api-Key: YOUR_API_KEY" \
-d '{"titles": ["Head of Sales"], "person_locations": ["United States"], "page": 1, "per_page": 100}'
The response gives you person records with names, titles, and companies. Depending on your plan and permissions, you get email addresses. According to Apollo's API documentation, rate limits are enforced per minute with a burst allowance per second, so you should plan for throttling instead of massive synchronous pulls.
Subscription prices are public. Basic is $49 per user per month billed annually, Professional is $79, Organization is $119 with a 3-user minimum, and Custom is negotiated. The fog starts with the credit mathematics inside those plans.
Apollo uses credits as currency, but users say precise credit costs per API call are hard to find. A r/UseApolloIo poster in April 2026 mentioned being happy with the API for prospecting but frustrated that they could not see their precise credit costs. Community tools for tracking rate limits exist because the limits are not simple published numbers.
Then the value of the data shifted. In May 2026, a r/UseApolloIo thread noted that the people search endpoint used to charge 1 credit for 100+ contacts and return first names, last names, and company websites. Users used this to build massive lists for almost nothing via email-finders. Apollo responded by obscuring last names and removing company websites from the results. The cheap-data hack the API was known for is over.
When I read these threads together, the practical advice is simple. Budget for negotiated credits plus unknown per-call costs, verify which fields come back unobscured before you build on them, and do not assume yesterday's cost per record still holds.
How do people scrape Apollo.io instead?
When API access requires a sales call, people find other ways. Scraping the web app is the standard workaround, but the tools are as unstable as the pricing.
The go-to used to be Apify's Apollo actors. Now, both Apollo Easy Scraper and Apollo Scraper 2.0, which once promised 50,000 leads from a search URL, are marked DEPRECATED. A r/Coldemailing thread in August 2026 asked "do you guys know scrapers or tools to scrap Apollo? Since the Apollo scraper from Apify went down?" The replies were mostly DM offers and self-promotion, which is typical for the scraper market.
Chrome extensions fill some of the gap. There is an Apollo Scraper extension reviewed by Salesforge in June 2026, a Microsoft Edge addon from April 2026 for exporting people and company data, and Apollo Exporter, which advertises unlimited lead exports even on the free plan.
Then there is DIY scraping using tools like Instant Data Scraper. A r/Coldemailing thread in May 2026 asked about scraping 250,000 to 400,000 records monthly. The most concrete answer was Apify at $1 for 1,000 leads, while other users suggested vendors that only charge for valid emails.
Here is the catch. Scrapers only see what the web app shows. Since Apollo removed last names and company websites from search results, a scraper that worked in 2024 returns thinner records in 2026. These tools break every time Apollo updates the front end, which is why those Apify actors died. Plus, you are scraping with an account that Apollo can suspend at any time.
If you need hundreds of thousands of records a month, your only durable options are negotiating the API or using a vendor that sells data programmatically by default. Scraping Apollo is a treadmill: the tool breaks, you patch it, and the data keeps shrinking.
Here is the working method as of November 2026, from the fastest route to the most durable. All of these assume you have a legitimate Apollo account, since the web app gates everything behind a login.
Route 1: Watch the network tab first. Apollo's web app talks to the same backend as the API. Every search you run appears as a JSON response in your browser. Open DevTools, run a search, filter for XHR requests, and read the payloads. You will see exactly what fields the app receives, which is often less than what the page actually renders. This is the only way to honestly size what a scraper can actually get you.
Route 2: Instant Data Scraper for one-off exports. This free Chrome extension reads the rendered DOM table. You paginate with your mouse and click to extract. Just expect the thin-record problem: last names and company websites were removed from search results in 2026, and a DOM scraper cannot recover fields the page no longer shows.
Route 3: Playwright with your own session. For recurring tasks, a headless browser using your logged-in session is the reliable pattern:
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch({ headless: false });
const context = await browser.newContext({
storageState: 'apollo-session.json', // your saved login state
});
const page = await context.newPage();
await page.goto('https://app.apollo.io/#/people');
// set your filters, then wait for the results table
await page.waitForSelector('table');
const rows = await page.$$eval('table tbody tr', (trs) =>
trs.map((tr) =>
[...tr.querySelectorAll('td')].map((td) => td.innerText.trim())
)
);
console.log(JSON.stringify(rows, null, 2));
await browser.close();
})();
Since the session state is a real login, respect the platform: throttle your requests, use one account, and keep volumes within your plan. Record selection limits apply to the web app just as they do to the API.
Route 4: Intercept the JSON instead of parsing the DOM. Inside Playwright, a page.on('response') handler that captures JSON responses from Apollo's backend endpoints gives you structured records without any table parsing. This is the pattern the deprecated Apify actors used, and it is the first thing to break when Apollo renames an endpoint or tightens the front end. Keep a fixture test so you notice a break within a day.
Route 5: Buy the plumbing. If you do not want to maintain selectors, Apollo Exporter and various Chrome extensions handle the session scraping for you. Apify actors did this server-side before they were deprecated. You are still on the treadmill: the vendor patches when Apollo changes, or the tool dies.
The order matters. Always do Route 1 first to see what is actually in the payload. Then pick Route 2 through 5 based on how often you need to run the export.
What do users say it actually returns?
Apollo's pages handle the access and credits, but the buyers handle the data quality. Three themes repeat across live threads.
Coverage is wide, but returns are often partial. In October 2026, a r/Coldemailing poster reported Apollo returning 40 to 50% of contacts, with a share of those rejected by catch-all domains. Users usually fix this by splitting the pipeline: use Apollo for volume, then run a separate verification step for the emails it returns.
The data decays fast. An SDR manager on r/SalesOperations described the cycle: imports from Apollo start failing within weeks, emails bounce, and titles go stale. This is why enrichment is a subscription, not a one-time purchase.
Credits burn quietly. In August 2026, a r/UseApolloIo poster reported AI features burning 10,000+ credits on non-US contacts. Another in September 2026 saw credits disappear through Claude MCP and Apollo's own AI agents. If your stack calls the API on a schedule, you need your own credit metering.
One more question from r/UseApolloIo to ask sales before you sign: how does Apollo use your CRM data, and can you opt out of your own data improving their database?
Should you build on the Apollo.io API?
If you need a large contact database for a sales workflow, Apollo is a reasonable core. The volume is real and the price per seat is low. Build on it when the workflow is Apollo-centric: enrichment inside the platform, outreach managed by Apollo, and a Custom plan negotiated with your eyes open.
Do not build on it when your product needs its own data layer. API access hidden behind sales negotiations, per-call credit costs that buyers cannot see, and fields that can be obscured without notice make Apollo a platform dependency. The change to the people search output is the warning: what your pipeline assumes about a field today can change tomorrow.
If you are building a product or agent that needs reliable company and people data, a purpose-built API is the cleaner foundation. NinjaPear returns company details, executives, employee counts, funding, and work emails from public sources. It is API-first and MCP-native, with published per-credit pricing and every call metered. Run the same 100-record test on it and on Apollo before you sign. The vendor that shows you its fill rates is the one you can actually verify. See also our guide to PDL's people API, the CRM enrichment vendor comparison, and the Clearbit alternatives comparison with pricing and migration.
Five checks before you commit: confirm API access and price in writing with Apollo sales, get per-call credit costs in writing, test the fields you need on 100 of your own records, meter your consumption from day one, and get the answer on your CRM data in the contract.
