Capterra Reviews Scraper

Export the reviews behind a Capterra software listing as structured data. Paste one or more product pages, get one row per review, up to 2,500 reviews per product.

Capterra's star rating is a single number standing in for thousands of individual opinions. This Actor gives you the opinions: who wrote each one, what they liked, what they did not, how long they had used the product, how big their company was, and whether they were offered anything in return for writing it.

Every row is checked against the product you asked for

This is the part worth reading first, because it is not a detail.

A Capterra product address looks like /p/135003/Slack/, and it reads as though the name identifies the product. It does not. Capterra resolves on the number alone and ignores everything after it, so /p/135003/Notion/ returns Slack, as a completely normal page, under the name you typed. Product numbers are not guessable either: 189442 is not a company anyone would guess, and a single mistyped digit lands on a real, different product rather than on an error.

So a scraper that trusts the address it was given can hand you one company's reviews filed under another company's name, and nothing in the output would look wrong.

This Actor reads the product identity back off the page and checks it against the number that was requested, on every page, not just the first. If they disagree, nothing from that page is kept and the run reports it. Every row then carries product_id, product_name and product_slug exactly as the page reported them, so the attribution is on the row itself and you can verify it without trusting us. Where the name you asked for and the name Capterra returned are different, the run summary says so explicitly.

The same care applies to the reviews themselves. A Capterra reviews page also carries the product's recommended alternatives, each with its own name, id and rating summary sitting in the same data. Reviews are read only from the one record that both carries reviews and matches the requested id.

What you get per review

Every row carries the whole review, not a summary of it.

Scores. The overall star rating, plus all five of Capterra's individual dimension scores: ease of use, customer support, functionality, value for money, and the reviewer's 0-10 answer to how likely they are to recommend the product. That last one is on Capterra's own 0-10 scale and stays there rather than being squeezed into five stars, because it answers a different question from the rating.

The text, in the fields the reviewer filled in. Capterra asks for pros and cons separately and this Actor keeps them separate, so you get pros and cons as their own columns rather than one blob you have to split later. On top of those: the review title, the reviewer's overall comments, any advice they left for other buyers, why they chose this product, and why they switched away from a previous one. Where a reviewer named the products they weighed against this one, or the product they moved off, those come through as lists.

Who wrote it. Job title, industry, company size band, and how long they had been using the product when they wrote. Whether Capterra validated them, and by what method. Whether they posted anonymously.

The incentive disclosure. Capterra records, per review, whether the reviewer was offered something in exchange, such as a gift card. That flag is in every row, with Capterra's own wording of the disclosure alongside it, so you can weight incentivised reviews differently or drop them entirely.

The vendor's reply. Where the software vendor publicly answered a review, the reply and its date are in the row. Some vendors answer almost every review and some answer none, which is itself worth knowing about a vendor.

Where the review came from. Capterra publishes reviews gathered on its sibling directories next to its own. Every row states which one it came from, so a mixed set never looks like a single-source one.

Input

Paste product page addresses, one per line. The reviews page address works too, and so does an id and slug pair like 135003/Slack.

Everything else is optional:

Input	What it does
Reviews per product	Stop after this many reviews for each product
Maximum products	Cap on how many products the run covers
Sort reviews by	Newest, oldest, highest rated, lowest rated, most recommended, or as served
Minimum / maximum overall rating	Keep only reviews in a star range
Reviewer company size	Keep only reviewers from companies of a given size
How long the reviewer used it	Free trial, under six months, up to two years, longer
Review source	Restrict to one of the directories Capterra draws from
Drop incentivized reviews	Leave out reviews written for a reward
Only reviews with both pros and cons	Drop the one-liners
Written on or after / before	Date range, as YYYY-MM-DD
Text contains	Keep only reviews mentioning a word or phrase
Maximum pages per product	Request ceiling, for when a narrow filter would otherwise read everything
Delay between page requests	Pacing, in seconds
Attempts per page	Retries for a page that came back incomplete

About the filters and the sorting

These are applied to the reviews after they are collected, not asked of Capterra.

That is a deliberate choice and worth explaining, because Capterra's review pages do have a sort and filter panel, and its controls do write parameters into the address bar. Requested directly, the site accepts every one of those parameters and returns exactly the same reviews it would have returned without them. We checked each one against a baseline confirmed identical across three consecutive requests: sorting, star rating, company size, reviewer role and length of use all came back with the same twenty-five reviews, indistinguishable from a parameter name we invented on the spot. Passing them through would have produced an Actor whose filter inputs did nothing at all, which is worse than not offering them.

So the filtering happens here, on fields that are present in the row you receive and that you can check for yourself. Two of Capterra's own facets, reviewer role and frequency of use, are not offered at all, because the review data carries no such field and there would be nothing honest to filter on.

One consequence worth knowing: a reviewer who did not state their company size or tenure cannot satisfy a filter on it, so those rows drop out when you set one. The run summary reports how many rows your filters removed, so the effect is visible rather than silent.

Limits, and how this Actor handles them

2,500 reviews per product, and it really is per product. Capterra publishes at most 100 pages of 25 reviews for any product, however many it holds. Slack has over 24,000 reviews and the site will show you 2,500 of them. That is the site's ceiling, not this Actor's, and asking for more cannot produce more.

The part worth stating plainly, because it decides whether this Actor is useful for more than one product at a time: the 2,500 is not a budget your run spends. It is a property of each product. Two large products in a single run each returned the full 2,500, the second one in a session that had already collected 5,000 reviews, with no slowdown and no errors. A separate run starting cold was served the identical reviews at pages 1, 50 and 100. So ten products in one run means 25,000 reviews, not 2,500 shared between them.

Past the ceiling Capterra does something worth guarding against: ask for page 101 and it answers with page 1 again, as a perfectly normal response carrying twenty-five genuine reviews and the correct product. Its own "more pages available" flag keeps saying yes well past the end, so it cannot be used to decide when to stop. A crawler that followed either signal would append silent duplicates to the end of every large product. This Actor tracks the reviews it has already collected and refuses to return any of them twice, and the run summary reports how many duplicates were blocked.

A product with very few reviews has no reviews page. Capterra redirects the review address for those products to the product profile, which answers normally and contains no reviews. That case is reported as an error with its own code rather than as a product with nothing to say, because a scraper that reported "no reviews" for a product with three would be giving you a confident wrong answer.

A product id that does not exist is reported as an error too, rather than as an empty result.

The number in the URL is what identifies a product. Capterra resolves on it and ignores the name after it, so /p/135003/Notion/ returns Slack. Every row states the product name the page actually reported, and the run summary flags any product whose name did not match the one you asked for.

Output

One dataset item per review. The key-value store holds a run summary, with per-product figures: the name Capterra resolved, how many reviews it holds in total, pages fetched, rows returned, rows removed by your filters, duplicates blocked, and why the crawl stopped for that product. Anything that could not be read lands in errors with a code.

Speed and cost

One page of 25 reviews every few seconds, paced deliberately rather than run flat out. Reading a product all the way to the site's ceiling is a hundred requests and took six to seven minutes in testing, for 2,500 reviews. Reading 100 reviews from each of ten products is a much shorter run. Use the reviews-per-product and maximum-pages inputs to set the ceiling you want before you start.

Long runs are bounded on purpose. A single page that stops responding is given up on rather than waited out, and each product has a wall-clock budget well above what a full read needs. If a product ever hits it, the reviews already collected are returned and the summary says what happened, instead of the whole run expiring with nothing to show.

Related

If you want the product profile rather than the reviews behind it, including the rating dimensions, review counts, starting price and pricing model as one row per product, use the Capterra Scraper Actor instead.