Travel & Hospitality
Hotel Price Intelligence API
You are selling or buying rooms against competitors who reprice several times a day. Without a comparative rate picture you are guessing at the only number that matters.
- OTAs and booking platforms
- Hotel revenue teams
- Travel management companies
- Metasearch sites
- Corporate travel software
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
Hotel pricing is unusual in that the competitive set is small, geographically obvious and repricing constantly. A 90-room property in a city centre is competing with perhaps eight other properties, all of whom change rates on weekday patterns, event calendars and each other. Everyone in that set is reacting to everyone else, and the reaction loop is measured in hours.
The practical difficulty is not analysis, it is collection discipline. A rate is only meaningful alongside the exact conditions it was quoted under — the stay dates, the length of stay, the occupancy, the rate plan, the cancellation terms, the channel and the point of sale. Strip any of those out and you end up comparing a non-refundable double to a flexible twin and calling it a price difference.
Collection also has to respect where the data comes from. Some rate data is available under commercial agreements with distribution partners. Some is published. Some sits behind terms of use that prohibit automated collection or redistribution entirely. The build has to be designed around which of those applies to each source, because getting that wrong is a commercial and legal problem rather than a technical one.
Who buys this
OTAs and booking platforms, Hotel revenue teams, Travel management companies, Metasearch sites, Corporate travel software
What the API returns
What comes back
- Comparative rates for a defined competitive set, by stay date and length of stay
- Rate plan detail: board basis, cancellation terms, occupancy and channel
- Availability state including restrictions such as minimum stay and closed-to-arrival
- Rate change events with the previous value and the time of change
- Rate parity observations across channels for the same property
- Lowest-available-rate series per property and date for charting
- Shoulder-date context so a single date is read against the dates around it
- Source and freshness metadata on every quoted rate
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/rates | Comparative rates for a property set and stay window |
| GET | /v1/properties/{id}/rates | Rate calendar for one property |
| GET | /v1/properties/{id}/availability | Availability and restrictions by date |
| POST | /v1/compsets | Define or update a competitive set |
| GET | /v1/changes | Rate and restriction changes within a time window |
| WS | /v1/stream | Push rate changes for watched properties as they are observed |
Request and response
illustrativeRequest
{
"compset_id": "cs_barcelona_gothic",
"stay": { "check_in": "2026-12-18", "nights": 2 },
"occupancy": { "adults": 2, "children": 0 },
"channels": ["brand_site", "ota_a", "ota_b"],
"currency": "EUR"
}Response
{
"compset_id": "cs_barcelona_gothic",
"stay": { "check_in": "2026-12-18", "nights": 2 },
"as_of": "2026-10-22T09:14:00Z",
"currency": "EUR",
"properties": [
{
"property_id": "prp_4411",
"name": "Subject property",
"lowest_rate": 214.00,
"rate_plan": "flexible_room_only",
"channel": "brand_site",
"availability": "open",
"restrictions": [],
"changed_at": "2026-10-22T06:40:00Z",
"previous_rate": 199.00
},
{
"property_id": "prp_4418",
"name": "Competitor 2",
"lowest_rate": 186.50,
"rate_plan": "non_refundable",
"channel": "ota_a",
"availability": "open",
"restrictions": ["min_stay_2"],
"changed_at": "2026-10-21T22:05:00Z",
"previous_rate": 186.50
}
],
"compset_position": { "rank": 5, "of": 8, "vs_median_pct": 9.4 },
"coverage": { "properties_quoted": 8, "properties_unavailable": 0 }
}Where the data comes from
| Distribution partner feeds | Rate and availability data supplied under a commercial agreement, which is the cleanest and most defensible source |
| Your own channel manager or PMS | Your live rates and restrictions, so the subject property is exact rather than observed |
| Published rate data | Where a source publishes rates under terms that permit automated collection and derived redistribution |
| Property reference data | Star rating, room count, location and facilities, so a competitive set is built on comparable properties |
| Event and holiday calendars | Local events and school holidays explain most of the large rate moves in a market |
| FX rates | Rates quoted in different currencies are not comparable without a consistent conversion basis |
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.
- Strict normalisation of every quote to a canonical rate definition before any comparison is made
- Change detection on a rate fingerprint rather than on price alone, so a cancellation-policy change is not recorded as a price cut
- Competitive set construction from location, class, room count and observed rate correlation, not just distance
- Deduplication of the same property appearing under different names and identifiers across channels
- Outlier screening for mis-keyed rates, which are common and badly distort a median
- Backfill of a historical rate archive so seasonality and event effects can be measured rather than assumed
- Coverage monitoring per property and date, with explicit gaps instead of silent interpolation
- Automated checks that each source is still being collected within its permitted terms
What it changes for the business
Pricing decisions on evidence
Revenue managers set rates against an observed market position rather than last year's spreadsheet.
Faster reaction
Rate-change alerts shorten the gap between a competitor moving and your response.
Parity control
Channel discrepancies on your own inventory become visible before a partner raises them.
Product differentiation for platforms
A booking platform that shows comparative context keeps the shopper from opening a second tab.
How it fits into your product
How it embeds
- REST for on-demand comparison, WebSocket for watched-property change streams
- Webhooks into your revenue management workflow or Slack for threshold breaches
- Compset definitions managed through the API so your customers can configure their own
- Rate calendar and position components you can embed, or raw JSON for your own UI
- Batch endpoints for overnight refresh across a large property portfolio
- Deployment inside your infrastructure where partner agreements require the data to stay put
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 collect rates from any site we name?
No, and we would not quote a build on that assumption. Many travel sites prohibit automated collection and redistribution in their terms of use. During discovery we map each source you want against what its terms actually permit, and design around the ones that do not allow it. Where a commercial feed is the only lawful route, that licence cost is identified before the build starts.
How fresh are the rates?
It depends on the source. A partner feed can be near real time. Polled sources are collected on a schedule set by politeness limits and volume, which in practice means hourly for high-value dates and daily for the long tail. Every rate carries an observation timestamp so your users are never shown a stale number as though it were current.
Is rate parity monitoring reliable?
For your own inventory, yes, because we can compare what you published against what each channel displays. Across other properties it is weaker, since a rate difference is often a legitimately different product rather than a parity breach. The API reports the observation and the rate conditions and leaves the judgement to you.
What about markets where our compset is tiny?
With three or four comparable properties the median is noisy and we would say so rather than dressing it up. In thin markets the useful output is change detection and restriction tracking rather than a position percentile.
Can we resell this data to our own customers?
That depends entirely on the source licences. Derived measures — position, change events, indices — are usually easier to redistribute than raw competitor rates. We design the response contract so the redistributable parts are clearly separated from the parts that are not.
Related blueprints
Hotel Revenue Optimisation API
Occupancy forecasts, recommended rates and demand signals per property and date, as the pricing engine inside hospitality software.
Travel Review Intelligence API
Topic-level sentiment, service issue detection and satisfaction movement from guest reviews, as an analytics layer for hospitality and travel software.
Flight Disruption Intelligence API
Delay risk and cancellation signals per flight, with push alerts, for booking platforms and travel management software.
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.