Paste GetApp reviews URLs, one per line, and the review section comes back as rows - who wrote it, the rating, the headline, the review text and the date, alongside the product's overall rating and total review count. Ten columns, one row per review.
One required field and two controls. The sort is the one worth thinking about.
The limit is per query, not per run: five products with a limit of a hundred is a hundred reviews from each, not a hundred altogether.
A review page defaults to whatever ordering flatters the listing. Lowest rated inverts that in one setting, and it is usually the reason to run this at all - the criticism is where a shortlist decision actually gets made.
Both ends of the timeline are available as sorts. That is what lets you separate a complaint that has been fixed from one that is still live - the oldest reviews describe the product people bought two years ago, which is not the product being sold now.
aggregate_rating and review_count describe the product rather than the individual review, so they repeat down the file. That is what lets you weigh one review against the average it sits in - a two-star among four hundred fives reads very differently from a two-star among nine.
These names are confirmed twice: they are the service's own declared list, shared with the other review scrapers on this pipeline, and they are the header row of every export we hold. What each column is for is below. What each will contain is not - the note explains why.
The names are solid. Everything past them is your first run's job, and here that caveat is unusually strong. We hold three run exports for this service and none of them contains a GetApp review. All eight review columns - product, author, rating, title, review, date, aggregate_rating, review_count - were empty on all three rows; only query and status carried anything. The three are not alike, either: two had been pointed at a placeholder address rather than at GetApp and came back http 404, while the third went to a real GetApp reviews URL and returned a different status entirely. What those runs establish is the export's shape, and nothing whatsoever about its contents. The column list they do confirm: the header row is identical across all three workbooks and matches the service's declared set exactly. Everything else - what a rating looks like, what format a date arrives in, whether aggregate_rating is a number or a string - is deliberately absent rather than guessed. The form also warns that anti-bot sites return a blocked status on the free pool, which is residential-only; that is the platform's own general warning and worth planning for. Run the free tier against one real product and read the header row and the first few values before you build on them.
All of them start from a reviews URL you can copy out of the site.
Set the sort to Lowest rated and export. You get the specific things buyers dislike about a competing product, in their words and with dates - a more honest feature-gap analysis than any comparison page either vendor would publish.
Run Least recent and Most recent against the same product. If a theme appears in both, it is a live problem; if it only appears in the old reviews, it was probably fixed - and no single page view will tell you which.
Because aggregate_rating and review_count repeat on every row, a single harsh review can be read in context rather than in isolation. That is the difference between a real signal and an outlier someone screenshotted.
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. Given that no run we hold has returned a real review, this is the part that matters most here: spend a few rows establishing what this export actually contains before you plan around it.
Roughly $2 per 1,000 reviews, the same flat rate as every other scraper on the platform. The limit is per query, so ten products with a limit of a hundred is a thousand rows - worth the arithmetic before you start.
Volume pricing, SLAs, dedicated workers and tailored onboarding for teams tracking a competitive set rather than a single product. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.One review site is one audience. These are the others worth having beside it.
The closest comparison, and a richer export: G2 splits each review into pros and cons as separate columns and records the reviewer's company-size band. Run both when a shortlist decision is worth the extra pass.
Early adopters rather than procurement committees. The same software often reads very differently in the two places, and the gap between them is usually where a product outgrew its first audience.
Reviews of the company rather than the software - billing, support, renewals. A vendor can score well on the product and badly on being a vendor, and buyers notice both.
Short answer: yes, when you only collect what is publicly visible on a product page - and that is all this service reads.
A GetApp product's review section is public. Anyone can read it without an account, and collecting publicly visible information for product and competitive research is long-settled practice. As long as the data is publicly available and the process does not disrupt the service, there are no federal laws against it.
These reviews describe people's working lives, though, which makes the personal-data question sharper than on a consumer site. author is a person, and a review's text can narrow down where they work. Publicly visible is not the same as free of obligation - if you store it, the GDPR and similar regimes apply regardless of where you got it. Analysing complaints in aggregate to improve a product is an easy case; building a file that identifies individual reviewers is not, and this service is not intended for it.
GetApp's terms restrict automated access, so this remains a question of terms. We touch nothing behind a login, read only what an ordinary visitor sees, 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.
Paste one GetApp reviews URL, set the sort, and read what buyers actually complained about. Your first 500 rows are free.
GetApp is one of the places business software gets reviewed by the people who had to live with the purchase, and like most review sites it is built for scrolling rather than analysis. You cannot sort it your own way across products, or line one vendor's criticism up against another's. This service turns a product's review section into a table: paste GetApp reviews URLs, one per line, and each review comes back as a row - the author, the rating, the headline, the body text and the date, alongside the product's own overall rating and total review count. Ten columns, one row per review.
Two controls shape the run. The limit is per query rather than per run, so ten products at a hundred each is a thousand rows, and the field takes a minimum of one. The sort offers five settings, and two of them are the reason to bother: Lowest rated gets you the criticism a listing will never lead with, and having Least recent alongside Most recent lets you check both ends of the timeline - a complaint that appears only in the oldest reviews has probably been fixed, and one that appears in both has not.
Keeping the review-level and product-level scores in separate columns is what makes the export analysable. rating is this review; aggregate_rating and review_count are the product, repeated down the file. A two-star review among four hundred five-stars is a different fact from a two-star among nine, and only the second pair of columns tells you which you are looking at.
One limit is stated plainly because it changes what to expect. We hold three run exports for this service and none of them contains a GetApp review - every review column was empty on all three rows. Nor did they fail identically: two had been aimed at a placeholder address rather than at GetApp, and the third reached a real GetApp reviews URL and returned a different status. What survives is the column list, and it survives well: the header row is identical across all three workbooks and matches the service's declared set. So the ten names above are dependable, and everything past them - what a rating looks like, what format a date arrives in, whether the aggregate is a number or a string - is deliberately absent rather than invented. The form also warns that anti-bot sites return a blocked status on the free pool, which is residential-only. Run one product on the free tier and read the first few rows yourself; your first 500 cost nothing and need no credit card. See pricing for current rates.