Travel & Hospitality
Travel Review Intelligence API
A property with four thousand reviews and a 4.2 average knows nothing useful. The average hides the one thing that is actually going wrong.
- Hotel groups
- OTAs and review platforms
- Property management systems
- Restaurant groups
- Tour operators
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 scores are a lagging, heavily compressed signal. A hotel sees its average slip from 4.4 to 4.2 over a quarter and has no idea why, because the number aggregates cleanliness, breakfast, check-in, noise, value and staff into one digit. By the time the average moves enough to notice, the underlying problem has been running for two months and has cost real bookings.
Underneath, the text is specific. Guests write about the air conditioning in rooms on the courtyard side, the queue at check-in between four and six, the breakfast that now stops at nine-thirty. Those are operationally actionable in a way a score is not. Extracting them reliably means topic-level sentiment with enough granularity to be useful and enough aggregation to be fair.
The constraints here are mostly about data rights and representativeness. Review text on most platforms belongs to the platform and the author, and the terms usually restrict bulk collection and redistribution. Your own first-party reviews and survey responses are yours; third-party review text generally is not, and a build that assumes otherwise is building on sand.
Who buys this
Hotel groups, OTAs and review platforms, Property management systems, Restaurant groups, Tour operators
What the API returns
What comes back
- Topic-level sentiment across a hospitality-specific taxonomy
- Issue detection with severity and the operational area responsible
- Satisfaction movement by topic over time, with change-point detection
- Emerging-theme detection for complaints that have no existing topic
- Comparison against a peer or portfolio baseline by topic
- Representative quotes per topic, where the source licence permits display
- Reviewer segment breakdown: trip type, source market, stay length
- Volume and coverage metadata so a topic conclusion is not drawn from four reviews
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/reviews/analyse | Analyse a batch of review or survey text |
| GET | /v1/properties/{id}/topics | Topic sentiment for one property |
| GET | /v1/properties/{id}/issues | Detected issues with severity and area |
| GET | /v1/properties/{id}/changes | Topic-level change points over a period |
| POST | /v1/compare | Compare properties or periods on the same topics |
| GET | /v1/taxonomy | The topic taxonomy and its definitions |
Request and response
illustrativeRequest
{
"property_id": "prp_4411",
"period": { "from": "2026-07-01", "to": "2026-10-21" },
"compare_to": { "from": "2026-03-01", "to": "2026-06-21" },
"segments": ["trip_type", "source_market"],
"min_mentions": 15
}Response
{
"property_id": "prp_4411",
"reviews_analysed": 1284,
"overall_score": 4.21,
"overall_change": -0.19,
"topics": [
{ "topic": "check_in_speed", "mentions": 146, "sentiment": -0.34,
"change": -0.41, "change_point": "2026-08-09",
"area": "front_office", "severity": "high" },
{ "topic": "cleanliness_bathroom", "mentions": 212, "sentiment": 0.52,
"change": 0.03, "area": "housekeeping", "severity": "none" },
{ "topic": "room_noise", "mentions": 88, "sentiment": -0.21,
"change": -0.06, "area": "maintenance", "severity": "medium",
"detail": "Concentrated in courtyard-facing rooms" },
{ "topic": "breakfast_hours", "mentions": 34, "sentiment": -0.44,
"change": -0.44, "emerging": true, "area": "food_beverage",
"severity": "medium" }
],
"segments": {
"trip_type": { "business": { "check_in_speed": -0.51 },
"leisure": { "check_in_speed": -0.22 } }
},
"suppressed": [{ "topic": "spa_facilities", "reason": "below_min_mentions" }]
}Where the data comes from
| Your first-party reviews and surveys | Post-stay surveys and direct reviews, which you own outright and can analyse without restriction |
| Review platform APIs | Official partner APIs where the platform offers one, which is the only defensible route to third-party review text |
| Your guest messaging and ticket logs | Complaints raised during the stay, which lead public reviews by days and are the earlier signal |
| Operational records | Occupancy, staffing levels and maintenance tickets, so a sentiment change can be matched to something that actually happened |
| Property and room reference data | Room type and location, which is how a noise complaint becomes a courtyard-side finding |
| Translation services | Reviews arrive in many languages, and analysing only the English ones biases the result towards one source market |
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.
- A hospitality-specific topic taxonomy rather than generic sentiment categories, built with the operator so topics map to teams
- Aspect-based sentiment at clause level, since a single review routinely praises the staff and condemns the shower in one sentence
- Change-point detection on topic sentiment series, which surfaces a step change weeks before the headline average moves
- Emerging-theme clustering for complaints that fall outside the taxonomy, with human review before a cluster becomes a topic
- Minimum-mention thresholds with explicit suppression, so no conclusion is drawn from a handful of reviews
- Language handling that analyses in the original where possible rather than translating first, which flattens nuance
- Validation against human-labelled samples per topic, reported as per-topic accuracy rather than one overall figure
- Drift monitoring on the taxonomy itself, because the vocabulary guests use changes with what properties offer
What it changes for the business
Specific, actionable findings
A named topic and a responsible area replaces a drifting average nobody can act on.
Earlier detection
Change-point detection on topics surfaces a problem weeks before it shows in the headline score.
Portfolio comparison
A group can see which properties share a problem and which have solved it.
Operational attribution
Matching sentiment moves to staffing and maintenance records turns opinion into a cost case.
How it fits into your product
How it embeds
- Batch analysis on a schedule plus on-demand scoring for newly arrived reviews
- Webhooks on new high-severity issues and on detected change points
- Topic and trend components ready to embed in an existing operations dashboard
- Portfolio endpoints so a group or a software vendor can analyse hundreds of properties overnight
- Taxonomy extension so an operator can add topics specific to their product
- Deployment inside your infrastructure where guest text cannot leave
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 pull reviews from every major travel site?
No. Most review platforms prohibit bulk collection and redistribution in their terms, and some offer no partner API at all. We work with your first-party reviews, your survey responses, your in-stay messaging, and whichever platforms you have an official data agreement with. If someone has told you they can scrape all of it for you, they are describing a legal risk rather than a product.
How reliable is topic-level sentiment?
Good for high-volume, well-defined topics such as cleanliness, check-in and breakfast — typically agreeing with human labellers at a rate we measure and report. Weaker for subjective topics like value for money, and weaker again in languages with thin training samples. We publish accuracy per topic rather than one headline number, because the headline number hides exactly the cases you would be misled by.
Are reviews representative of guests?
They are not, and no analysis fixes that. Reviewers skew towards strong experiences in both directions and towards certain source markets and trip types. Segment breakdowns make the skew visible, and pairing public reviews with post-stay surveys gives a more balanced picture than either alone.
Can we display the quotes you extract?
Only where the source licence allows it. Your own survey responses are generally fine subject to the consent you collected. Third-party review text usually is not, even when you can lawfully analyse it. The API separates displayable quotes from analysis-only sources so your front end cannot accidentally publish the wrong one.
What about fake reviews?
We can flag patterns consistent with inauthentic reviews — timing clusters, template-like language, implausible reviewer histories — as a quality signal. We would not present that as a determination that a specific review is fake, because the evidence rarely supports that strength of claim about an individual case.
Related blueprints
Hotel Revenue Optimisation API
Occupancy forecasts, recommended rates and demand signals per property and date, as the pricing engine inside hospitality software.
Accessibility Information API
Verified accessibility features for hotels, attractions and routes, with the verification method attached to every claim.
Hotel Price Intelligence API
Comparative hotel rates, availability movement and rate-change alerts, delivered as a data layer inside your booking or revenue product.
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.