Software Review Data: What a G2 or Capterra API Returns

Copy this line to your agent to pull reviews for a software product.

set up https://monid.ai/SKILL.md and use capterra /search_software then /get_product_reviews

Review sites are where buyers say what a product is actually like, in their own words, at length. That makes them the most useful qualitative source in B2B research and the most uneven one. On 2026-09-07 the same catalogue returned twenty-five reviews for a household name and zero for a product two rows away in the same search. This guide runs through Monid, the OpenRouter for agent tools.

What does a software review record contain?

Five fields, and one of them does work you would otherwise pay a model to do.

The record

capterra/get_product_reviews for a well-known product on 2026-09-07 returned twenty-five reviews shaped like this:

{
  "title": "Slack: Essential for Desk Based Workforces",
  "date": "July 25, 2026",
  "rating": "5.0",
  "pros": "Slack is the best way for a desk based workforce to communicate...",
  "cons": "..."
}

The field that matters most

pros and cons arrive as separate fields. The review site's own form asks for them separately, so the reviewer did the splitting, not a classifier.

That is a structured sentiment axis handed over for free. Most review-mining pipelines start by running a model over prose to separate praise from complaint, which costs money and introduces error. Here the boundary is authored by the person who had the opinion, which is both cheaper and more reliable than any inference.

What it means for analysis

You can count themes in cons across a competitor's reviews without a sentiment model at all. Simple term frequency over the complaint field is a legitimate first pass, and it is the fastest route from raw data to something a product team will read.

What is not there

No reviewer identity beyond what the title carries, no company size or industry on the record we measured, and no verified-purchase flag. If your analysis needs to segment by reviewer type, that is not in this shape. Firmographics would have to come from a separate join, the kind compared in the firmographics cost breakdown.

📖 See also Extract Pricing and Free Trial Information From Websites

Why does a niche product return zero reviews?

Because coverage follows attention, and the long tail is genuinely empty rather than merely thin.

The measurement

Two products from the same catalogue on the same day:

Both were real entries returned by the same search endpoint. One has a review corpus; the other has a listing and nothing behind it.

Why this is a design problem, not a data problem

A pipeline that pulls reviews for a list of competitors and averages ratings will silently weight the famous ones, because they are the only ones contributing rows. The niche products do not drag the average down; they are absent from it. That is worse than being wrong, because the resulting number looks reasonable.

The check that costs nothing

Record the count alongside every aggregate:

if len(reviews) < 10:
    result = {"rating": None, "n": len(reviews), "note": "insufficient"}

A rating without its sample size is not a measurement. This is the same rule we applied to engagement rates in the Instagram accuracy post, and it matters more here because the variance across products is so large.

The identity trap in the same endpoint

Searching for one product name returned three rows: two different entries both called "Slack" with different ids, plus a third product called "Slack AI Kotaro". Name matching picks one of those at random and quietly analyses the wrong catalogue entry.

The reviews endpoint requires both product_id and product_name, and it says so in a 422 if you send only one. That looks redundant and is a useful guard: the id does the selecting, and the name has to agree with it.

How do you pull reviews for a product?

Three steps. Discovery is free.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Step 1. Resolve the product to an id

What it does. Gets the identifier the reviews endpoint needs, and shows you the near-duplicates.

The endpoints. capterra/search_software, billed per call, takes query.

The call.

monid run -p capterra -e /search_software --query '{"query": "project management"}'

What comes back. Twenty rows with name, id, slug and url. Look at the whole list rather than taking the first row, because that is where the duplicate names are visible.

What it costs. About a cent per call. Current figures at monid.ai/tools.

Step 2. Pull the reviews

What it does. Returns the review corpus, already split.

The endpoints. capterra/get_product_reviews, per call, requires product_id and product_name together.

The call.

monid run -p capterra -e /get_product_reviews \
  --query '{"product_id": "135003", "product_name": "Slack"}'

What comes back. data.reviews with title, date, rating, pros and cons, plus a page field for paging.

What it costs. Same order.

Step 3. Count themes in the complaint field

What it does. Turns prose into something a product team acts on, without a model.

The call. No endpoint:

from collections import Counter

terms = Counter()
for r in reviews:
    for phrase in KNOWN_THEMES:            # "pricing", "onboarding", "support"
        if phrase in (r["cons"] or "").lower():
            terms[phrase] += 1

share = {k: v / len(reviews) for k, v in terms.items()}

Start with a fixed theme list rather than open-ended extraction. It is cheaper, it is reproducible across runs, and it produces a series you can compare over time, which open-ended summarisation does not. Fixing the definition before you measure is the same discipline as computing an engagement rate you can defend.

📖 See also The Best Amazon Reviews API in 2026 (We Tested Them)

What can review data actually tell you?

Three things it is good at, and one it is regularly asked to do and cannot.

What competitors are bad at, in customers' words

The cons field across a competitor's reviews is the closest thing to a free win-loss study. Recurring complaints are the objections your sales team will hear, phrased the way buyers phrase them.

Which features people mention unprompted

Reviewers write about what they used, so mention frequency is a rough proxy for what matters in daily use rather than what a website claims. It is noisy and it is honest.

Whether sentiment is moving

Because every record carries a date, you can bucket by quarter and watch whether complaints about a theme are growing. That is a trend, and trends survive the noise that individual reviews carry.

What it cannot do: tell you the market's opinion

Review corpora are self-selected. People write reviews when they are delighted, annoyed, or incentivised by a vendor campaign, and the silent majority never appears. A four-and-a-half star average is a statement about who chose to write, not about the customer base. Treat the text as qualitative evidence and the score as barely quantitative.

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-09-07. The table gives billing shape rather than figures; shape drives design and current numbers live on monid.ai/tools.

The last row needs a caveat rather than a recommendation. On 2026-09-07 it returned a 503 carrying block_type: "retryable_protection", attempts: 3 and retry_after: 60, and it returned the same thing on 2026-09-02. Five days apart is a pattern, not an unlucky afternoon, so plan on the Capterra side and treat G2 as a bonus. The block itself is at least well-mannered: it says it already retried three times and when to come back, which is the good kind of failure described in rate limiting a third party API.

When is review data the wrong input?

Three cases.

You need a representative sample. It is self-selected and always will be. For anything that needs to generalise to a population, this is the wrong instrument and a survey is the right one.

You are comparing across catalogues. Ratings on different sites are computed differently, from different populations, on different scales and with different moderation. A 4.5 on one is not a 4.5 on another, and averaging them produces a number with no referent.

The product is niche. Zero reviews is a common outcome, as we measured. For a long-tail competitor you will need customer conversations rather than a scraped corpus, and no endpoint fixes that. The same coverage cliff appears in private company funding data.

And the disclosure: this is Monid's blog and we sell per-call access to all of the endpoints above, including the G2 pair that has been blocked on both days we tested. Publishing that is more useful than a table that pretends every row works.

Conclusion

The best thing about this data is the shape it already comes in. Reviews arrive with pros and cons as separate fields, authored by the reviewer rather than inferred by a classifier, which removes the most expensive step in most review-mining pipelines before you write any code.

The thing to design around is coverage. Twenty-five reviews for a household name and zero for a niche product in the same catalogue is not an anomaly; it is the shape of the whole long tail. So record the sample size beside every aggregate and refuse to report a rating computed from four reviews.

And resolve products by id. One search returned three rows sharing a name, and the endpoint requiring both id and name together is a guard worth appreciating rather than working around.

Free next step: search your own product category and read the whole result list rather than the first row. The duplicate and near-duplicate names you find are the ones that would have quietly corrupted a competitive table. Start at monid.ai.

FAQ

Last updated September 2026.