Home/Offers/Travel & Hospitality/Hotel Revenue Optimisation API

Travel & Hospitality

Hotel Revenue Optimisation API

Revenue management at most independent properties is one experienced person, a spreadsheet and a strong memory. That works until they are on holiday.

Hotel groups and independents
Property management systems
Channel managers
Revenue management software
Serviced apartment operators

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

The gap in this market is not at the top. Large chains run revenue management systems that cost six figures a year and employ people to operate them. The eighty-room independent, the serviced apartment operator with four buildings, the small group with a part-time revenue manager — they are pricing on instinct, a competitor glance and a pickup report they read on Mondays.

What they need is not a smaller version of an enterprise system. It is a forecast of how a given date will fill, a rate recommendation with a reason attached, and a clear signal when a date is behaving unlike its usual pattern. The reason matters as much as the number: a revenue manager who cannot see why the system wants 212 euros will override it, and then stop using it.

Forecasting room demand is tractable because the booking curve is informative. By thirty days out, the shape of accumulated bookings for a date tells you a great deal about where it lands, and the residual uncertainty concentrates in the last week. The modelling difficulty is group bookings, which arrive in lumps and can make a date look either disastrous or sold out depending on one contract.

Who buys this

Hotel groups and independents, Property management systems, Channel managers, Revenue management software, Serviced apartment operators

Category: Travel & Hospitality

What the API returns

What comes back

Occupancy forecasts per property and date with a confidence interval
Recommended rate per date and rate plan, with the reasoning exposed
Pickup and booking-pace tracking against the same date last year and against the property's own curve
Demand signals from events, capacity changes and search interest
Unconstrained demand estimates for dates that sold out early
Length-of-stay and shoulder-date effects for a proposed rate change
Anomaly flags where a date is pacing unlike its historical pattern
Revenue impact estimates for accepting or declining a group enquiry

Endpoints

Method	Path	Returns
GET	/v1/properties/{id}/forecast	Occupancy forecast by date with intervals
GET	/v1/properties/{id}/recommendations	Recommended rates with reasoning
GET	/v1/properties/{id}/pace	Booking pace against curve and prior year
POST	/v1/properties/{id}/simulate	Estimate the effect of a proposed rate change
POST	/v1/properties/{id}/groups/evaluate	Revenue impact of a group enquiry
GET	/v1/properties/{id}/anomalies	Dates pacing unlike their historical pattern

Request and response

illustrative

Request

{
  "property_id": "prp_4411",
  "dates": { "from": "2026-12-15", "to": "2026-12-22" },
  "rate_plans": ["flexible", "non_refundable"],
  "constraints": { "floor_rate": 120.00, "ceiling_rate": 420.00,
                   "max_daily_change_pct": 12 }
}

Response

{
  "property_id": "prp_4411",
  "currency": "EUR",
  "generated_at": "2026-10-22T04:00:00Z",
  "dates": [
    {
      "date": "2026-12-18",
      "on_books_pct": 54.2,
      "forecast_occupancy": { "p50": 86.1, "p20": 78.4, "p80": 93.0 },
      "pace_vs_last_year_pct": 7.8,
      "current_rate": 199.00,
      "recommended_rate": 214.00,
      "reasoning": [
        { "factor": "pace_ahead_of_curve", "effect_pct": 6.1 },
        { "factor": "compset_median_above_current", "effect_pct": 4.4 },
        { "factor": "local_event_demand", "effect_pct": 3.0,
          "detail": "Conference at venue 1.2km, 18-19 Dec" }
      ],
      "constraint_applied": null
    },
    {
      "date": "2026-12-21",
      "on_books_pct": 22.0,
      "forecast_occupancy": { "p50": 48.9, "p20": 38.1, "p80": 60.2 },
      "pace_vs_last_year_pct": -14.2,
      "current_rate": 178.00,
      "recommended_rate": 162.00,
      "reasoning": [{ "factor": "pace_behind_curve", "effect_pct": -9.0 }],
      "anomaly": { "code": "pace_below_p10", "severity": "medium" }
    }
  ]
}

Where the data comes from

Your PMS reservation data	Arrivals, departures, length of stay, rate and channel — the booking curve is built from this and nothing substitutes for it
Your rate and restriction history	What you charged and when, so the model can learn your own price response rather than a generic elasticity
Competitive rate data	Observed compset rates, under terms that permit this use — see the rate intelligence build for how that is sourced
Local event and venue calendars	Conferences, concerts and sporting fixtures, which explain most of the large single-date demand moves
Air and rail capacity data	Scheduled seat capacity into the destination, a useful leading indicator for a leisure market
Climate and holiday calendars	School holidays by source market and weather seasonality, both of which shift the booking curve

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

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.

Booking curve models per property, segment and day of week, since a city hotel's Tuesday curve has nothing in common with its Saturday
Quantile forecasting rather than point estimates, because a revenue decision needs the downside not the mean
Group bookings modelled separately and excluded from the transient curve, as one contract otherwise corrupts the pace signal
Unconstrained demand estimation for dates that closed out, so historical sell-outs do not teach the model that demand was exactly capacity
Price response estimated from your own rate history with regularisation, falling back to a segment prior where your history is thin
Recommendation decomposition into named factors with their individual effect, so every number can be explained to the person overriding it
Hard constraints — floors, ceilings, maximum daily movement — applied after optimisation and reported when they bind
Forecast accuracy tracked per property and horizon, with alerting when error widens beyond the validated band

What it changes for the business

Revenue decisions that survive absence

The property keeps pricing sensibly when the one person who understood the spreadsheet is away.

Earlier reaction to soft dates

Pace anomalies surface a weak date while there is still time to do something about it.

Group decisions on numbers

An enquiry can be evaluated against displaced transient revenue rather than accepted because the room is empty today.

A sellable module for software vendors

A PMS or channel manager can offer revenue management without building a forecasting team.

How it fits into your product

How it embeds

Pulls from your PMS or channel manager on a schedule, or receives pushed reservation deltas
Recommendations returned for approval by default, with optional write-back to the channel manager once trust is established
Multi-property endpoints so a group or a software vendor can refresh a whole portfolio overnight
Forecast and pace components ready to embed in an existing revenue screen
Constraint configuration per property, set by the revenue manager rather than by us
Deployment inside your infrastructure where reservation data cannot leave the estate

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 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

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

Will it push rates automatically?

Only if you ask for it, and we would not recommend starting there. The sensible sequence is recommendations for approval, then automatic movement within a narrow band for far-out dates, then wider authority once the property has watched it for a season. Handing price control to a model on day one is how properties end up with a bad weekend and no trust in the system.

How much history do you need?

Two full years of reservation data is comfortable, one year is workable with wider intervals, and less than that means the first months lean on segment priors and the forecasts should be read sceptically. A new property has no booking curve, and no amount of modelling invents one.

Does it handle group business?

It separates group from transient and evaluates enquiries against displaced transient revenue. It does not manage group negotiation, contracts or function space, and the displacement estimate is only as good as the transient forecast for those dates — which, far out, is wide.

What about events we know about and you do not?

You can enter them, and the model treats a user-entered event as a demand signal with a learned effect once it has seen one or two instances. The event calendar coverage is good for large venues and poor for a wedding at the hotel down the road.

Can you guarantee a revenue improvement?

No. We can measure forecast accuracy against held-out history and report it honestly, and we can show whether recommended rates were above or below what was actually charged and how those dates resolved. Attributing revenue change to pricing alone is not possible when demand, capacity and the market are all moving at the same time.

All Travel & Hospitality offers →

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.

Discuss This Build Browse All Offers