Indeed carries employee reviews for hundreds of thousands of employers - a star rating, a written review, the reviewer's job title and location, and how many people found it helpful. This service turns a company's review page into a table: one row per review, twenty-one columns, with a stable review id you can deduplicate repeat pulls on.
The input is one employer's review page, and the size of the run is something you set rather than something you discover.
The query is a company. You can pass the full URL of an Indeed company page - https://www.indeed.com/cmp/TEKsystems - or just the identifier from it, TEKsystems. The published reference puts the batching ceiling at 1000 queries in one request, so a list of employers is a single job rather than a thousand of them.
How many reviews come back is yours to choose. The documented limit defaults to 100 reviews per query, and it is the parameter that decides your bill, because billing follows rows. Two other controls shape the slice rather than its size: sort takes helpfulness or rating_desc, and cutoff takes the oldest timestamp you care about - the reference notes that using cutoff overrides sort and returns the newest records first.
That distinction matters because a company's review page is usually far longer than anything you want to export. Every row we pulled carried review_count, the total Indeed holds for that employer, alongside the handful we had actually asked for - and the two numbers were nowhere near each other. Decide the depth deliberately; the export will not decide it for you.
No search to build and no filters to reproduce - you name the employer and say how deep to go.
/cmp/.Several companies at once is the same job - the reference allows up to 1000 queries in a single request.
The header we measured, in order. Where a description quotes a fill rate it is counted from 40 real reviews of a single employer - which is enough to establish that a column exists and what shape it takes, and not enough to tell you how often it is populated for a company that is not that one.
July 1, 2026 - not as an ISO date. Parse it before sorting.rating they arrive as strings.?id= at the end of url, and all 40 were distinct.The five category ratings are one field, not five. On our 40 rows comp_benefits_rating, culture_rating, management_rating, job_security_rating and worklife_rating were populated on exactly the same 17 rows and empty on the same 23 - never a partial set. Indeed asks for them as an optional block, so plan for all five or none rather than testing each column. They also arrive as strings while rating arrives as a number, which is the kind of difference a spreadsheet hides and a script does not.
Each of these is measured from the 40 reviews we hold. They are properties of Indeed's review form and of the export, not opinions about it.
Every review carries a sixteen-character review_id, and on all 40 of our rows it was exactly the ?id= at the end of that review's url. All 40 were distinct. That makes it the column to deduplicate on when you pull the same employer again - and it also means you can reconstruct the link from the id, or recover the id from a link somebody sent you, without a lookup.
date comes through as July 1, 2026 - the wording Indeed prints on the review - and every one of our rows matched that shape. It sorts alphabetically into nonsense and it will not group by month until you parse it. Do that on the way in. The reviews themselves arrived newest first in both of our runs, which is convenient but is not a substitute for a real date column.
aggregate_rating and review_count are employer-level facts repeated on every row - the company's overall score and how many reviews Indeed holds for it. Averaging aggregate_rating across your rows just returns itself, and counting rows is not counting reviews: on our export the pool that review_count described was many times larger than the slice we had asked for. Group by company before you use either.
Indeed lets a reviewer leave both out, and many do: across our 40 rows job_title was present on 32 and location on 29. What is there is free text - our locations included "City, ST" pairs, bare state names and lowercase typing. Neither column is safe to join on or to facet by without cleaning, and neither is safe to assume: filtering on location silently drops the reviewers who never filled it in.
Where a company's reviews are more useful as a table than as an endless scroll.
Your Indeed page is the first thing a candidate checks and the last thing anyone reads systematically. Exported, it becomes something you can actually work: split by current_employee to separate leavers from staff, group by job_title to see which function is unhappy, and read the five category scores where reviewers left them rather than guessing which one is dragging the average down.
Batch a list of the companies you compete with for candidates - the reference allows up to a thousand in one request - and pull the same depth of reviews for each. aggregate_rating gives you the headline comparison for free, and the review bodies tell you what the number is made of. That is a far more honest benchmark than a salary survey, because nobody wrote it for you.
Pull the same company on a schedule and deduplicate on review_id; what accumulates is only the new reviews. That turns a static page into a signal - a run of low ratings from one job title, or a sudden burst after a reorganisation, is visible in the diff long before it moves the average that everyone else is looking at.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that it is pay-as-you-go.
For every new account, one time. No credit card. All scrapers unlocked. At the documented default of 100 reviews per company that is five employers pulled in full before you pay anything.
Roughly $2 per 1,000 reviews. Because limit sets how many reviews come back per company, your bill is something you choose up front rather than something you discover afterwards - a hundred employers at fifty reviews each is the same spend as fifty employers at a hundred.
Volume pricing, SLAs, dedicated workers and tailored onboarding for teams tracking employer sentiment across a large list of companies on a repeating schedule. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.Employees review their employers in more than one place, and each site attracts a slightly different person. These two cover the ground Indeed does not.
The same question asked of Glassdoor, where pros and cons are separate fields and reviewers also rate the CEO and the outlook.
What the same employer is advertising right now - useful next to the reviews, because what people say and what a company is hiring for rarely tell the same story.
Short answer: yes, with one thing to be careful about that does not apply to most of our scrapers.
Indeed's company review pages are public. Anyone can read them without an account, and collecting publicly visible pages for research is long-settled practice. As long as the data is publicly available and the process does not disrupt the site, there are no federal laws against it.
The care is warranted because reviews are written by people, and unlike a job listing a review can be about a person. Indeed does not attach a name - there is no author column in this export - but job_title, location and date together can narrow a small team to one individual, and the review body sometimes names a manager. If you are publishing or sharing anything derived from this, aggregate it. If you are storing it, treat it as personal data even though no name is in the file.
Indeed's terms restrict automated access, so this remains a question of terms. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports self-delete after 30 days.
The questions we hear most. Something else? Talk to us - humans write the answers, not bots.
https://www.indeed.com/cmp/TEKsystems, or just the identifier from it, TEKsystems. It supports batching with up to 1000 queries in a single request, so a list of employers is one job.query, company, aggregate_rating, review_count, rating, title, review, job_title, location, date, current_employee, helpful, unhelpful, comp_benefits_rating, culture_rating, management_rating, job_security_rating, worklife_rating, url, review_id and status. One row per review. That header was identical on every run of ours that carried this shape, populated or not.limit defaults to 100 reviews per query, and since billing follows rows it is the parameter that sets your bill. Note that review_count on each row tells you how many reviews Indeed holds for that employer in total, which is usually a much bigger number than the slice you pulled - do not read one as the other.sort accepts helpfulness or rating_desc, and cutoff takes the oldest timestamp you want, which per the reference overrides sort and returns the newest records first. fields narrows the columns. In both of our own runs, with no sort set, the reviews arrived newest first.comp_benefits_rating, culture_rating, management_rating, job_security_rating and worklife_rating were filled on exactly the same 17 rows and empty on the same 23 - never some but not others. So test one of them, not five, and expect a substantial share of reviews to carry only the overall rating. One more trap: the five arrive as strings while rating arrives as a number.review_id. It is Indeed's own sixteen-character identifier for the review, it was distinct on all 40 of our rows, and it was also the ?id= at the end of that review's url on every one of them. Matching on reviewer text or date instead will merge genuinely different reviews, because short reviews repeat and many share a date.job_title, location and date in combination can still identify someone at a small employer, so aggregate before you publish.Name the employer, set how deep to go, and get the reviews as rows - rating, body, job title, location, the five category scores and a stable id to track them by. Your first 500 rows are free.
Indeed holds employee reviews for a very large number of employers, and for many companies it is the review page a candidate reads before an interview and a competitor reads before a poaching campaign. The page itself is built for browsing one review at a time: a star rating, a headline, a paragraph or two, a job title where the reviewer supplied one, and a helpfulness counter. That works when you are reading. It works badly when the question is about the whole page - which function is unhappy, whether the score is moving, what the difference is between what leavers say and what current staff say. The Indeed Reviews Scraper answers those by turning a company's review page into a table: one row per review, twenty-one columns, with a stable identifier you can track a review by across pulls.
The input is an employer rather than a search, which makes this service unusually simple to drive. The published reference accepts either a full company URL or the bare identifier that appears in it, and it allows up to a thousand queries in a single request, so comparing a field of competitors is one job rather than a hundred. The depth of each pull is a parameter - the documented limit defaults to a hundred reviews per company - and because billing follows rows, that parameter is also your bill. Two further controls shape which reviews you get rather than how many: a sort that accepts helpfulness or rating-descending, and a cutoff timestamp that, per the reference, overrides the sort and returns the newest records first.
Three properties of the data are worth knowing before you build on it, and all three are visible in the export we measured. The first is that two of the twenty-one columns are not about the review at all: aggregate_rating and review_count describe the employer and repeat unchanged on every row, so averaging the first across your rows returns itself, and the second describes a pool that is normally much larger than the slice you exported. The second is that the five category ratings - pay and benefits, culture, management, job security and work-life balance - behave as a single optional block: on our rows they were populated together on the same seventeen reviews and absent together on the other twenty-three, never partially. They also arrive as strings while the overall rating arrives as a number. The third is that the date is written as Indeed prints it, in the style July 1, 2026, rather than as an ISO date, so it needs parsing before it will sort or group.
Two honest caveats about the evidence behind this page. Everything counted above comes from forty reviews of one employer, which is enough to establish what a column is and what shape its values take, and not enough to tell you how often any column is filled for a company that is not that one - the fill rates are illustrative, not predictive. And this scraper meets Indeed's anti-bot defences: most of our own attempts returned nothing at all, with the reason recorded in the status column, and the service is listed internally as needing a residential proxy. Runs can fail and retries are normal. What does not vary is the shape of the export, which was identical on every run that carried it. Start free: your first 500 rows cost nothing and need no credit card.