Paste an Apollo people or company search URL, add a JSON export of your own Apollo cookies, and get the result back as rows: name and title, email and phone, company and domain, industry, employee figure, location and a LinkedIn URL. Twelve columns, in the order Apollo's own export puts them.
Build the search in Apollo as you normally would, then hand over the address and the cookies that prove it is your account.
The cookies are what let the run see your Apollo account. Without them there is nothing to read - this is not a public-page scrape.
Whatever filters you set in Apollo are already encoded in the address bar. Copy it, paste it, and the run reproduces that search - no rebuilding the query in a second tool, no filter that quietly means something different here.
A people search and a company search both come back in the same twelve columns, with a type column carrying the distinction. One parser, one table, whichever way you searched.
The two fields you actually join on arrive parsed rather than buried in a profile blob. domain matches your CRM's account records; linkedin_url matches everything else.
What the export carries: who the record is, where they work, and the two identifiers you join on.
Two things we would rather state than let you assume. The first: the table below names the twelve columns and says what each field is for - and it stops there. It does not tell you whether employees is a count or a band, what vocabulary type uses, or whether any field arrives as a number or as text. Those are answers a populated export gives, and every run export we hold came back with a header row and no data rows, because this service reads your Apollo account and our archived runs carried no session. Publishing a confident guess in place of those answers would be worse than publishing nothing.
The second: this one is not a public-page scrape. It needs a JSON export of your own app.apollo.io cookies, taken from a browser where you are logged in, and it reads what that account can already see. That is a different arrangement from everything else on this site, and it carries different obligations - the legal section below says exactly what they are rather than leaving you to find out.
Run a small free-tier job on one of your own searches. The header row and the first few rows of that file are the definitive answer for the records you actually care about.
The export's header row, in order. Descriptions say what each field is for; they deliberately claim nothing about its format, units or vocabulary - see the note above.
Two things to settle before you build against this. The column set above is solid - the XLSX header row of three separate run exports and the published column list agree on all twelve names in this order. What is not settled is what the cells contain: every export we hold is a header with no rows beneath it, so this page says nothing about types, units or vocabularies, and neither should your schema until you have run one. And the run needs your own Apollo cookies, so what you can export is bounded by what your Apollo account and plan already allow - this tool moves that data into a file, it does not widen your access.
The input is the Apollo URL from your address bar, plus a JSON export of your own Apollo cookies. Both kinds of search come back in the same twelve columns.
A few examples of what an Apollo search is worth once it is a file rather than a screen.
Build the filter once in Apollo, then take the result as rows and slice it however your team actually splits work - by industry, by employee figure, by location. Paging through the UI to count a segment is the part this removes.
Join the export on domain against your account records and on linkedin_url against your contacts. What matches is noise; what does not is the list worth working. Both identifiers arrive as their own columns for exactly this.
Re-run the same search later and keep both files. Titles change, headcounts move and people leave - a stored history is the only way to see that, because the live view only ever shows you today.
No subscription, no minimum, no recurring bill. Your first 500 rows are on us - after that, pay-as-you-go at the same flat rate as every other scraper here.
Every new account, one-time. No credit card required. Per-query limits, file upload and every export format included.
Roughly $2 per 1,000 rows. The pre-flight estimator shows the row count and credit cost before a run starts - no surprise bills, no compute units to translate.
Volume pricing, dedicated workers and an SLA for running a large set of searches on a schedule. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.These three need no account of yours to run, and they answer the questions an Apollo export leaves open.
The company side of the same record, from the public profile rather than from Apollo's index. Useful when you want to check an employee figure against its source.
Contact details from a company's own website, keyed by domain. The natural second pass on the rows where Apollo's email column came back thin.
Build the list from scratch rather than from a seat you are paying for. Different starting point, same destination - a table of companies you can work through.
This one is different from everything else here, and the difference is worth reading rather than skimming: it runs inside your own Apollo account, not on a public page.
Every other scraper on this site reads pages any visitor can see, with no login involved. This one does not. It needs a JSON export of your own app.apollo.io cookies, and it reads what your logged-in account can already reach. Nothing here defeats a paywall or widens your access - the run sees precisely what you see, and your Apollo plan's own limits still apply. Treat those cookies like the credential they are: they authenticate your account, so paste them only into tools you trust, and rotate them by logging out of Apollo if you ever think they have leaked.
Because it is your account, your agreement with Apollo governs what you may do with the output. Apollo's terms place restrictions on bulk export and on redistributing their data, and those restrictions are between you and Apollo - we are not a party to them and cannot waive them on your behalf. If you are planning volume, or building a product on top of the output, read your contract or take advice rather than relying on a general rule about public data, because the general rule is not the one that applies here.
The people rows are personal data. Names, job titles, email addresses, phone numbers and LinkedIn URLs identify individuals, and in the EU and UK that puts the whole export under the GDPR - as the controller, you need a lawful basis, you owe those people transparency about where their data came from, and you must honour objections and erasure requests. B2B contact data is not carved out of that. We run no third-party trackers on the data layer, and your exports auto-delete after 30 days, but the obligations that matter here attach to what you do next, not to the file.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
Your first 500 rows are free - no card, no subscription. After that it is $0.002 per row, flat.
Apollo is a sales-intelligence platform, and the searches you build in it live behind your account rather than on a public page. The Apollo Scraper turns one of those searches into a file. You submit the search URL from your address bar - a people search or a company search, one per line, or as a CSV, XLSX, TXT or Parquet upload - together with a JSON export of your own Apollo cookies, and the result comes back as rows carrying the name and job title, the email and phone number, the company and its domain, the industry, the employee figure, the location and a LinkedIn URL.
Two things about this page are unusual, and both are deliberate. The first is that it needs your credentials. This is not a public-page scrape: the run presents your session to Apollo and reads what your account can already see, so it neither defeats a paywall nor widens your access, and your plan's own limits still apply. Because it is your account, your agreement with Apollo governs what you may do with the output, and the people rows are personal data that put the export under the GDPR with you as the controller.
The second is what the data dictionary does not say. The twelve column names and their order are corroborated by two independent sources - the header row of three separate run exports and the published column list - so we state them plainly. But every export we hold is a header with no rows beneath it, because those archived runs carried no Apollo session. So the dictionary names each column and says what it is for, and claims nothing about its type, its units or its vocabulary. Publishing a confident guess in place of a real answer would be the more damaging choice.
Take a small free-tier run against one of your own searches and the header row and first few rows of that file are the definitive answer for the records you care about. Your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.