Travel & Hospitality
Destination Intelligence API
Every travel product needs to answer where and when. Most answer it from editorial instinct and last year's booking mix.
- OTAs and metasearch
- Destination marketing organisations
- Tour operators
- Hotel groups
- Travel media
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
Destination decisions inside travel companies are made with surprisingly little structure. Marketing picks the campaign markets from what sold last year. Merchandising ranks destinations by margin. Editorial writes the best-time-to-visit paragraph from whatever the previous version said. There is rarely a shared, measured picture of how a destination actually behaves across the year.
The underlying data exists and is mostly open. Climate normals describe weather by week rather than by season. Flight capacity filings show where airlines are adding and cutting seats months ahead. Event calendars explain the price spikes. Search and booking patterns show when interest in a destination forms relative to when people travel. Aggregated, that is a far better answer to when should I go than a paragraph of received wisdom.
The caution is that destination scoring slides easily into asserting that one place is better than another, which is both unfalsifiable and commercially awkward. Scores are only defensible when they are scored against a stated purpose — beach suitability in March, walkability for a family, crowding relative to the destination's own year — and when the components are visible.
Who buys this
OTAs and metasearch, Destination marketing organisations, Tour operators, Hotel groups, Travel media
What the API returns
What comes back
- Week-by-week seasonality profiles including climate, crowding and price level
- Interest signals showing when demand for a destination forms relative to travel dates
- Scheduled air capacity and route changes with effective dates
- Event and festival calendars with expected demand impact
- Purpose-specific destination scores with visible component weights
- Comparable destination sets for substitution and alternative suggestions
- Crowding indicators measured against the destination's own annual pattern
- Practical travel context: visa regime, currency, local holidays, typical costs
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/destinations/{id} | Profile, seasonality and current context for one destination |
| GET | /v1/destinations/{id}/seasonality | Week-by-week seasonality components |
| GET | /v1/destinations/{id}/events | Event calendar with demand impact |
| POST | /v1/score | Score destinations against a stated purpose and travel window |
| POST | /v1/compare | Compare destinations on the same components |
| GET | /v1/capacity/changes | Scheduled air capacity additions and cuts |
Request and response
illustrativeRequest
{
"purpose": "family_beach",
"travel_window": { "from": "2027-04-03", "to": "2027-04-18" },
"origin": "MAN",
"candidates": ["faro", "malta", "costa_blanca", "crete", "sicily"],
"weights": { "weather": 0.4, "crowding": 0.2, "cost": 0.25, "access": 0.15 }
}Response
{
"purpose": "family_beach",
"travel_window": { "from": "2027-04-03", "to": "2027-04-18" },
"scored": [
{
"destination": "faro",
"score": 81,
"components": { "weather": 78, "crowding": 72, "cost": 84, "access": 92 },
"notes": [
"Sea temperature still below 18C in early April",
"Direct capacity from MAN up 11% year on year"
]
},
{
"destination": "malta",
"score": 76,
"components": { "weather": 74, "crowding": 81, "cost": 71, "access": 79 },
"notes": ["Easter week overlaps the window; accommodation prices step up from 2 April"]
}
],
"events_in_window": [
{ "destination": "sicily", "event": "Easter processions, Trapani",
"dates": "2027-04-09/2027-04-11", "demand_impact": "high" }
],
"method": { "crowding_basis": "relative_to_destination_annual_mean",
"weather_basis": "1991-2020 climate normals" }
}Where the data comes from
| Climate normals | Long-run weekly climate records from national meteorological services, which are open and far more useful than seasonal averages |
| Published flight schedules | Filed airline schedules showing capacity by route and month, which lead demand by several months |
| Event and festival calendars | Compiled from official tourism board and venue publications, where terms permit reuse |
| Aggregated interest signals | Search and booking-intent data in aggregate form only, under sources that permit derived redistribution |
| Official tourism statistics | National arrival and occupancy statistics, which anchor crowding to something measured |
| Your own booking data | Optional — lets interest and seasonality be calibrated to your actual customer base rather than a generic traveller |
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.
- Seasonality decomposed into separate climate, price, crowding and access components, because a single best-time score hides disagreement between them
- Crowding normalised against each destination's own annual pattern rather than across destinations, which otherwise just ranks by size
- Purpose-specific scoring with caller-supplied weights, so the API never asserts a single universal ranking
- Capacity change detection from successive schedule filings, since the revision is the signal rather than the level
- Event impact estimated from historical price and occupancy response, not assigned by hand
- Comparable-destination sets built from observed substitution behaviour where booking data allows, falling back to attribute similarity
- Explicit method metadata on every score, so a component can be audited rather than trusted
- Coverage and freshness reporting per destination, with thin-data destinations flagged rather than scored confidently
What it changes for the business
Merchandising with evidence
Destination ranking and campaign timing rest on measured seasonality rather than last year's mix.
Better editorial at scale
Best-time-to-visit content can be generated per destination and refreshed when the underlying data moves.
Demand anticipation
Capacity filings and interest signals give months of warning before booking volume shifts.
Credible alternatives
When a destination is full or expensive, substitution suggestions are grounded in observed behaviour.
How it fits into your product
How it embeds
- REST for profiles and scoring, with caller-supplied weights so your product defines what good means
- Batch scoring across a large destination catalogue for overnight merchandising refresh
- Seasonality chart and comparison components, or structured JSON for your own visualisation
- Webhooks on capacity changes and newly announced events in destinations you watch
- Localisation of destination names, notes and event titles
- Optional calibration against your own booking history, run inside your environment if the data 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 tell us the single best destination for a customer?
No, and a product that claims to is overselling. The API scores destinations against a purpose and a weighting you supply, and returns the components so the answer can be explained. Change the weights and the ranking changes, which is honest rather than evasive.
Where do the interest signals come from?
Aggregated search and booking-intent data from sources whose terms permit derived commercial use, plus your own booking history if you choose to supply it. We do not use individual-level behavioural data, and we apply aggregation thresholds so no small cohort is identifiable.
How far ahead is the crowding estimate meaningful?
Patterns repeat well at a weekly resolution, so a typical-year view is reliable. A specific future week is not: a currency move, a new route or an unexpected event will shift it. Treat it as the normal shape of the year plus known events, not a forecast.
Is the event calendar complete?
It is good for major, annually recurring events and for destinations with an active tourism board that publishes. Smaller local events are patchy, and the API reports event coverage per destination so you can see where the calendar is thin instead of assuming an empty list means a quiet week.
Can we use the climate figures in customer-facing copy?
Yes, with the basis stated. They are climate normals over a stated reference period, not a forecast for the week your customer is travelling. We return the reference period in the response specifically so that distinction survives into your copy.
Related blueprints
Travel Itinerary Generation API
Generates day-by-day itineraries from traveller preferences, with sequenced routing and real opening hours, for booking and planning products.
Hotel Price Intelligence API
Comparative hotel rates, availability movement and rate-change alerts, delivered as a data layer inside your booking or revenue product.
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.