G2 Reviews Scraper

A software product's G2 reviews, exported as a spreadsheet. Each row carries the review's rating, headline, full text and both dates, the product's own aggregate rating and category list, and the two fields that turn a pile of opinions into something segmentable: the reviewer's job title, and the size band of the company they work for.

Each review also arrives split back into the three questions every G2 reviewer answers — what they like, what they dislike, and what problem the product solves. That split is what makes a complaint findable.

Accepted input

productSlugs is required and takes one or more product slugs, one per line, such as pipedrive. A pasted product page link works too and is reduced to the slug inside it. A slug is lowercase and carries no spaces and no query string; the page to start from is a separate field rather than something appended to the slug.

Slugs are not derivable from product names — Agentforce Sales is agentforce-sales-formerly-salesforce-sales-cloud — so they are worth copying rather than typing. Every row G2 Category Scraper produces carries the product's slug in its slug field.

maxItems bounds each product separately and defaults to 100. Reviews arrive ten to a page, so 100 is ten pages per product and 0 removes the bound. The cap is per product rather than per run because a run given twenty products is asking for a comparable slice of each.

order selects G2's own review ordering: relevance, most recent, most helpful, highest rated or lowest rated. It defaults to relevance, which is what the site serves with no ordering asked for.

startPage sets the page each product begins at and defaults to 1.

{
  "productSlugs": ["pipedrive"],
  "order": "most_recent",
  "maxItems": 100,
  "startPage": 1
}

Response fields

{
  "product_slug": "pipedrive",
  "product_name": "Pipedrive",
  "product_url": "https://www.g2.com/products/pipedrive/reviews",
  "product_categories": ["CRM", "Email Marketing", "Sales Analytics"],
  "product_rating": 8.7,
  "product_rating_best": 10,
  "product_review_count": 3118,
  "page": 1,
  "review_id": 13260876,
  "review_url": "https://www.g2.com/survey_responses/13260876",
  "title": "Visual Pipelines, Helpful AI Setup, and Great Value",
  "review_body": "The pipelines give a great visual representation of …",
  "sections": [
    {
      "question": "What do you like best about Pipedrive?",
      "answer": "The pipelines give a great visual representation of …"
    }
  ],
  "review_rating": 5,
  "review_rating_best": 5,
  "date_published": "2026-08-13T04:22:22-05:00",
  "date_modified": "2026-08-13T04:22:23-05:00",
  "reviewer_name": "Gavin A.",
  "reviewer_job_title": "Director",
  "reviewer_company_size": "Small-Business (50 or fewer emp.)",
  "reviewer_id": 9033304,
  "reviewer_profile_url": null,
  "product_id": 1619,
  "product_uuid": "4020c23b-cfa1-43a6-a5d4-17eb3494c795",
  "vendor_id": 1201,
  "video_review": false
}

Fields absent from a review are returned as null rather than omitted, so every row has the same shape.

review_body and sections are the same prose twice, and the difference between them is the point. G2 asks every reviewer three questions and the standard review-body field concatenates all three answers together with nothing marking the joins, so a search of review_body for a complaint also matches the praise beside it. sections is that prose split back into the questions as they were put, each with the answer as it was written. The three are not broken out into three named columns here, because the questions are worded per product and matching them on keywords would mislabel an answer rather than fail to find one.

reviewer_job_title and reviewer_company_size are read from the review page rather than from its structured data, and they are the fields that make a review set worth segmenting: the same complaint from a fifty-person company and from an enterprise are different findings.

review_rating is out of 5 and product_rating is out of 10, in the same row, and neither is rescaled. Both are G2's own numbers on G2's own scales, which is why review_rating_best and product_rating_best are published beside them rather than assumed.

review_id is the only stable key a review has, and it is what a repeated run should de-duplicate on. review_url is its permalink.

vendor_id groups several products under one company, which is how a vendor's whole portfolio is recognised across separate runs.

Behaviour on partial results

A product slug that G2 serves nothing for is logged and skipped, and the run continues with the next one. A product that exists and has no reviews returns a successful run with no rows for it.

The walk over a product ends on G2's own next control rather than on a page coming back short, because the last page of a three-thousand-review product is usually full and a full page is not evidence that another one exists. A page request that runs past the end is served as the last real page instead of as an error; the run notices that the page served differs from the page asked for and stops there rather than collecting it again.

review_id is occasionally null across a whole page. That happens when the page's structured data and its markup disagree about how many reviews are on it: rather than pair each review with an identifier that might belong to a different one, the identifiers are withheld and the reviews are published without them. The run log says so when it happens. The prose, ratings, dates and reviewer fields are unaffected.

Frequently asked questions

Why did the first row take so much longer than the rest? Because the first request of a run is where G2 checks the connection before it will serve anything, and that check takes time. Measured on 2026-08-22, a first read answered in 23.1 seconds and the one after it in 15.5. A run that appears to sit still for twenty seconds before its first row is behaving normally.

Which order should a repeated run use? most_recent. Relevance is G2's default and it is the right ordering for a single read, but it is not a stable sequence to page through: a review that moves between requests can be collected twice or missed entirely. Recency is fixed once a review is published, so a run repeated weekly against most_recent sees the new reviews at the front and nothing shifts underneath it.

How many reviews does a product have in total? product_review_count states the figure G2 computes its aggregate from, across the whole product. It is not the number of rows a run will return: maxItems bounds that, and G2 publishes no page count, so the walk asks for the next page until the site says there is none.

Do pages overlap, and does a walk need de-duplication? No, and not for that reason. Pages 1, 2 and 3 of one measured product shared no review identifiers at all. A repeated identifier is dropped if one appears, but that guard is a safety net rather than the load-bearing part. De-duplication is worth doing across separate runs, on review_id, because the product will have gained reviews between them.

Why is reviewer_profile_url empty on most rows? Because most reviewers do not have a public profile. reviewer_id is still populated, so repeat reviewers can be recognised across a dataset without one.

Where does the summary of what reviewers like and dislike come from? Not from here. G2 publishes a short list of praised and criticised traits per product on its category listings, and nowhere on the product's own pages, so G2 Category Scraper is where that comes from. This Actor is the evidence underneath it.

Is a G2 account, cookie or API key required? No. No account, session cookie or key of any kind is supplied to the Actor or needed by it.

Related Actors

G2 Category Scraper exports a software category in its ranked order, with each product's rating, review count, price band and the traits reviewers praise and complain about. Every row carries the slug this Actor takes, so it is where a run starts when the products are not already known.