E-commerce & Retail
Review Sentiment API
A four-star average tells you almost nothing. The same score hides a product that everyone likes and a product that half your customers love and half find unusable.
- Retailers
- Marketplaces
- Brand manufacturers
- Commerce software vendors
- Quality teams
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Review data is one of the richest signals a retailer holds and one of the least processed. The star rating gets displayed, the text gets shown to shoppers, and the aggregate insight — which specific attribute of which product is generating complaints, and whether that started three weeks ago — is left in the text where nobody reads it at scale.
Buyers and quality teams end up discovering problems through returns data, which is months of lag and real money. The reviews often said it earlier: a zip failing, a battery degrading, sizing running small since a supplier change. Those complaints are specific, they cluster, and they are detectable well before the return rate moves.
Doing this properly means working at the level of topic and aspect rather than document. A review that praises the design and condemns the battery is not neutral, and scoring it as such destroys the signal. It also means being careful with the text itself: reviews are written by identifiable people, and aggregating them into a product signal is a different thing from republishing them.
Who buys this
Retailers, Marketplaces, Brand manufacturers, Commerce software vendors, Quality teams
What the API returns
What comes back
- Aspect-level sentiment per product: build quality, sizing, battery, delivery, instructions, value
- Complaint topics with volume, trend and first-observed date
- Emerging-issue detection on topics that are rising faster than review volume
- Quality signals correlated against return and warranty data where you hold it
- Comparison of aspect sentiment against category and peer-product baselines
- Representative anonymised quotations per topic, subject to your usage rights
- Language detection and multilingual analysis with per-language volumes
- Suspicious-review indicators, flagged as signals for review rather than verdicts
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/analyse | Analyse a batch of review or support text |
| GET | /v1/products/{id}/aspects | Aspect-level sentiment for one product |
| GET | /v1/products/{id}/topics | Complaint and praise topics with trend |
| GET | /v1/alerts/emerging | Topics rising abnormally across the catalogue |
| GET | /v1/categories/{id}/baseline | Category aspect baselines for comparison |
| POST | /v1/taxonomy | Define or extend the aspect taxonomy for your categories |
Request and response
illustrativeRequest
{
"product_id": "JKT-NORD-2210",
"window": { "from": "2026-07-01", "to": "2026-10-21" },
"compare_to": "category_baseline",
"include": ["aspects", "topics", "quotes"],
"min_topic_volume": 8
}Response
{
"product_id": "JKT-NORD-2210",
"reviews_analysed": 1842,
"mean_rating": 4.1,
"aspects": [
{ "aspect": "warmth", "sentiment": 0.78, "mentions": 902, "vs_category": "+0.19" },
{ "aspect": "sizing", "sentiment": -0.34, "mentions": 611, "vs_category": "-0.41" },
{ "aspect": "zip_quality", "sentiment": -0.52, "mentions": 188, "vs_category": "-0.48" },
{ "aspect": "value", "sentiment": 0.21, "mentions": 430, "vs_category": "+0.03" }
],
"topics": [
{ "topic": "zip separates after short use", "volume": 141, "trend_30d": 2.6,
"first_observed": "2026-08-14", "severity": "high" },
{ "topic": "runs one size small", "volume": 388, "trend_30d": 0.2,
"first_observed": "2025-11-02", "severity": "medium" }
],
"emerging": [
{ "topic": "zip separates after short use", "lift_vs_expected": 3.4,
"note": "coincides with supplier change 2026-08-01" }
],
"quality_flag": { "return_rate_correlation": 0.61, "suggested_action": "inspect_component" }
}Where the data comes from
| Your own review data | Reviews on your storefront, which you hold and may analyse — the cleanest and least encumbered source |
| Marketplace review feeds | Where an official API or partner feed grants access; collection terms differ sharply between marketplaces and are checked per source |
| Support tickets and chat transcripts | Often richer than reviews about defects, and already inside your business |
| Return reasons and warranty claims | What turns a sentiment signal into a quality signal with a cost attached |
| Product and supplier metadata | Category, components and supplier, so a defect can be traced to a batch or a sourcing change |
| Translation and language resources | Needed where your reviews span languages and the aspect taxonomy must hold across them |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Aspect-based sentiment extraction rather than document-level scoring, so mixed reviews contribute correctly to each aspect
- A category-specific aspect taxonomy, because the attributes that matter for outerwear and for power tools do not overlap
- Topic discovery over clustered phrasings, with human curation of the resulting labels before they reach a dashboard
- Trend detection that normalises against review volume, so a sales spike is not misread as an emerging defect
- Correlation against return and warranty data to separate dissatisfaction from genuine product failure
- Language-model extraction constrained to the review text, with every attributed topic traceable to the sentences that produced it
- Validation against a human-labelled sample per category, with per-aspect precision and recall reported rather than one global accuracy figure
- Aggregation thresholds so no topic or quotation is published from a volume small enough to identify an individual reviewer
What it changes for the business
Defects found earlier
Component and sourcing problems surface in review text weeks before the return rate makes them obvious.
Sharper buying decisions
Aspect sentiment against a category baseline tells a buyer what to fix or drop, not just what scored badly.
Better listings
Persistent sizing and expectation complaints are usually a content problem that can be fixed in the description.
Supplier conversations with evidence
A specific, dated, quantified complaint topic is a far stronger position than an average rating.
How it fits into your product
How it embeds
- Batch analysis for backfilling historical reviews, then incremental processing as new text arrives
- Webhooks on emerging-topic detection into your quality or merchandising workflow
- Aspect and topic endpoints your existing product dashboards can render without a new front end
- Taxonomy management so your category teams own the aspect definitions rather than inheriting ours
- Deployment inside your environment where support transcripts cannot leave your infrastructure
- Per-market configuration so language handling and thresholds differ by region where they need to
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you analyse reviews from any marketplace?
No. Some marketplaces provide review data through an official API or partner programme, and some explicitly prohibit automated collection and redistribution of review content. We check each source during discovery and build around the ones that permit your intended use. Your own reviews and support text are always available to you and are usually the better starting point anyway.
Will it detect fake reviews?
It produces indicators — timing clusters, phrasing similarity, reviewer behaviour patterns — and presents them as signals for human review. It does not render verdicts. Declaring a review fraudulent on model output alone is a decision with consequences for a real person, and it should not be automated.
How accurate is aspect sentiment?
Good on common aspects with plenty of mentions, weaker on sparse ones, and that varies by category. We measure it against a human-labelled sample from your own data and report precision and recall per aspect. A single headline accuracy number would hide exactly the variation you need to see.
Is reviewer personal data processed?
Only what is necessary, and the output is aggregate. Topics and aspect scores are published above a minimum volume threshold so they cannot be traced to one reviewer, and whether representative quotations may be surfaced at all depends on your terms with the reviewer and the platform.
Can it tell us why returns are rising?
It can tell you which complaint topics are rising alongside the returns and how strongly they move together. That is correlation with a plausible mechanism, not proof of cause. It is usually enough to direct an inspection at the right component, which is the practical point.
Related blueprints
Return Probability API
Predicted return likelihood and probable reason for an order line, scored before dispatch so you can intervene while it still matters.
Product Content Enrichment API
Standardised attributes, category assignment and completion of missing product fields, returned as structured data your catalogue can ingest.
Competitor Price Monitoring API
Competitor prices, discounts and stock status for your catalogue, delivered as a change feed your pricing tools can act on.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.