Submit domains or Trustpilot page links and get the reviews themselves - title, full text, star rating, helpfulness count and date, each with the author's name, country and how many reviews they've written. Up to 100 per business by default.
That's the whole difference from the other two Trustpilot services, and it changes both the shape of the data and the size of the bill.
The Trustpilot Scraper and Trustpilot Search Scraper return one row per business, carrying a rating and a review count. This returns the reviews behind that count - the title, the full text, the stars, the date and the author.
So the arithmetic is different. A hundred businesses is a hundred rows on those services and potentially ten thousand here, because the default is up to a hundred reviews per business. That's not a drawback, it's simply what review data is - but it's worth knowing before you queue a large list.
Results come back grouped by business rather than as one flat pile, so a run covering many companies stays organised without you needing to re-sort it.
Same input as the lookup service - a domain or a Trustpilot page link.
The cut-off is the useful one for repeat runs - see the scope controls below.
Most review datasets give you sentiment. These two give you something rarer - a way to weigh it.
author_reviews_number is how many reviews a person has written anywhere. author_reviews_number_same_domain is how many of those were for the business you're looking at. Read together they say a lot. Someone with a long reviewing history across many companies is a different kind of source from an account whose only review is the one in front of you - and a reviewer with several reviews of the same business is a different case again.
None of that proves anything on its own, and we won't pretend it does: a first-time reviewer is usually just a first-time reviewer. But when you're weighing whether a five-star run or a cluster of one-star reviews reflects genuine customer experience, having the author's history in the same row is the difference between reading sentiment and auditing it. Combine it with review_date to spot reviews that arrived suspiciously close together.
Four settings shape a run. The cut-off is the one that turns this from a one-off pull into something you can repeat cheaply.
The main cost lever. One business is up to a hundred rows unless you lower it, so a thousand-domain list at the default is a very large job. Set it to what your analysis actually needs.
Set the oldest date you care about and the run stops there. Re-run later with the cut-off at your last collection and you only pay for what's new - the cheapest way to keep a review dataset current.
To page deeper into a business's reviews. Worth knowing the skip value has to be a multiple of twenty - an odd number won't do what you expect, and it's the kind of detail that costs an afternoon.
You can filter to a language or take all of them; the documented options are English, Spanish and German alongside the default and all. Sorting by recency is the documented option.
A note on the language filter: only those three languages are named in the reference, so if you need another one, check it on the free tier rather than assuming - we'd rather you found out for two rows than for twenty thousand.
All three come straight out of the documented response.
The date is a Unix timestamp. review_date arrives as a number of seconds, not a readable date - and unlike some review services there's no formatted counterpart alongside it. Convert it on the way in, or every chart you build will be sorted correctly and labelled uselessly.
Don't sum total_reviews. It's the business's overall review count, repeated identically on every one of its review rows. Aggregate it carelessly across a hundred reviews and you'll report a hundred times the real figure. Take the first value per business, or get it from the Trustpilot Scraper, which returns one row per business precisely so this isn't a problem.
Reviews come grouped by business. The response nests one collection per query rather than returning a single flat list, so flatten deliberately if your pipeline expects rows. The upside is that query appears on every review, so nothing is ambiguous once flattened.
Each row is a single review, carrying the business it belongs to alongside it - so an export stands on its own without a join back to the profile.
Half the rows carry no review text. Across 100 rows of real output, review was populated on 50% and title on 94% - many reviewers leave a headline and a star rating and nothing else. If you are running sentiment or keyword analysis, filter on review being non-empty first, or your denominator will be wrong. reply is present on 43%.
Where the text matters more than the score.
A rating tells you there's a problem; the text tells you which one. Pulling reviews across your own business and your competitors' and reading them for recurring themes surfaces the specific failures customers care about - usually a shorter and more surprising list than internal assumptions suggest.
Competitors' negative reviews are free research into where their product breaks and which promises they can't keep. That's both a positioning input and a list of things not to do - and it costs a fraction of a customer survey.
When a score seems out of line with a business's reputation, the author history fields let you look properly: how established the reviewers are, how many wrote about this company alone, and whether the reviews arrived in a cluster. Useful for due diligence and for defending your own listing.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. On this service that's a few hundred reviews - enough to read one business properly and check your language filter works before scaling.
Roughly $2 per 1,000 reviews. A row is a review here, not a business, so the reviews-per-business setting is your main lever - and a cut-off date on repeat runs keeps ongoing collection cheap.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams tracking review sentiment across many businesses continuously. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Customers review the same business in more than one place, and the two accounts often differ.
The same job on the platform most customers reach first, with a richer field set that includes owner replies and review images. Reading both together shows where a business's story changes by audience.
One row per business instead of one per review - rating, review count, claimed and closed flags plus contact details. The right tool when you want the score across a market rather than the text behind it.
This service sits differently from the other two Trustpilot tools, and it's worth saying why rather than reusing their answer.
Reviews are published to be read - that's the entire point of a review platform, and collecting publicly available information for research is long-established practice. But unlike a business profile, a review has an author. The output carries a reviewer's display name, an identifier, their country and their reviewing history, and that combination is personal data even when the name is a first name and an initial.
Two practical consequences. You become a controller of that data, so the usual duties apply - a lawful basis for holding it, and a route for objection and erasure requests. And if you republish reviews, remember the text is the author's own writing: quoting a review in your marketing is a different act from analysing it internally, and attribution and context both matter. Aggregate analysis - themes, sentiment over time, ratings distribution - is the easiest use to justify and the most common.
Our own practice: minimise what you keep. If you only need sentiment, you rarely need the author fields, and dropping them at import is the simplest way to reduce your obligations. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
review_id to de-duplicate at the boundary.review_date is a Unix timestamp - seconds, not a readable date - and there's no formatted counterpart documented alongside it. Convert it as you import. Sorting works fine on the raw value; it's only the labels that will be unreadable if you don't.total_reviews was summed. It's the business's overall count repeated on every one of its review rows, so adding it up across a hundred reviews multiplies it by a hundred. Take the first value per business, or get it from the Trustpilot Scraper, which returns one row per business.Paste domains or page links and get the full text, ratings, dates and author history behind every rating. Your first 500 rows are free - enough to read one business properly.
A star rating compresses everything a customer thought into a single digit. The Trustpilot Reviews Scraper gets the rest of it. Submit domains or Trustpilot page links - up to 1,000 per run - and each business returns its reviews as rows carrying thirteen fields: a review identifier, the title and full text as written, the star rating, how many people found it helpful, the date, the business's total review count, and four fields describing the author, namely their display name, an identifier, their country, and how many reviews they have written in total and for this business specifically. Results arrive grouped by business rather than as one flat pile, and every review carries the query that produced it.
The first thing to understand is how differently this behaves from the other two Trustpilot services. Both of those return one row per business, carrying a rating and a review count. Here a row is a review, and the default is up to a hundred reviews per business - so a hundred domains can be ten thousand rows rather than a hundred. That is simply the nature of review data, but it makes the reviews-per-business setting the main cost lever on the page. The complementary setting is a cut-off date: tell a run the oldest review you care about and it stops there, so re-running later with the cut-off set to your last collection means you only pay for what has appeared since. Paired with the review identifier for de-duplication, that turns an expensive one-off pull into cheap ongoing collection. A skip setting pages deeper into a single business's reviews, and it has one quirk worth knowing - the value must be a multiple of twenty.
Three details will save an importer rewrite. The review date is a Unix timestamp in seconds with no formatted counterpart documented alongside it, so convert on the way in or your charts will sort correctly and label unreadably. The total review count is a business-level figure repeated identically on every one of that business's review rows, which means summing it across a hundred reviews reports a hundred times the real number - take the first value per business, or read it from the Trustpilot Scraper, which returns one row per business precisely so this cannot happen. And the response nests one collection per query rather than returning a flat list, so flatten deliberately. On language filtering, English, Spanish and German are the options named in the reference alongside a default and an all setting; anything else is worth testing on the free tier rather than assuming.
Two fields make this dataset unusually useful. Knowing how many reviews an author has written in total, and how many of those were for the business in front of you, lets you weigh a rating rather than simply record it - an account whose only review is the one you are reading is weaker evidence than a long and varied history, and reviews clustered tightly in time are worth examining. Neither proves anything alone, and a first-time reviewer is usually just a first-time reviewer, but combined with the timestamp they turn sentiment reading into something closer to auditing. That capability comes with a responsibility, and it is the reason this page's legal position differs from its siblings: a review has an author, so the output contains personal data even when a name is only a first name and an initial. You become a controller of it, with the usual lawful-basis and erasure duties, and republishing review text raises attribution questions that internal analysis does not. The practical advice is data minimisation - if you only need sentiment and themes, drop the author columns at import. Nothing behind a login is touched and exports auto-delete after 30 days. Start free: your first 500 rows cost nothing and need no credit card.