Insurance & Claims
Travel Risk Intelligence API
A traveller does not need a country risk rating. They need to know whether the thing happening three hundred kilometres away affects their flight on Thursday.
- Travel insurers
- Assistance providers
- Corporate travel managers
- Booking platforms
- Employer duty-of-care 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
Travel risk information is published at the wrong granularity to be useful. Government advisories cover whole countries and update slowly, because that is what they are for. A general strike in one region, a volcanic ash plume drifting across one flight corridor, or flooding closing one airport road is invisible at that resolution — and those are the events that actually disrupt trips and generate claims.
For an insurer the consequence is that exposure is unknown until the claims arrive. A weather event closes an airport and the claims function discovers how many policyholders were travelling through it when the notifications start. The same information, available two days earlier and mapped against the in-force book, is the difference between managing an event and reacting to it.
For a corporate travel programme the problem is duty of care. The obligation is to know where your travellers are and whether they are affected, and most programmes satisfy it with a country-level advisory feed and a spreadsheet. Matching live disruption against actual itineraries is straightforward engineering, and the reason it is not standard is that nobody has joined the itinerary data to the event data at the right resolution.
Who buys this
Travel insurers, Assistance providers, Corporate travel managers, Booking platforms, Employer duty-of-care teams
What the API returns
What comes back
- Destination risk scores by category: security, health, weather, transport disruption, civil unrest
- Trip-level risk assessment matched against a specific itinerary and date range
- Live disruption events geolocated and scored for travel impact, not newsworthiness
- Airport, route and carrier disruption indicators including delay and cancellation patterns
- Severe weather tracking with projected tracks and affected transport infrastructure
- Health and outbreak notices from official sources, with the travel-relevant restrictions extracted
- Portfolio exposure: which in-force policies or travellers are affected by a live event
- Alerting with configurable thresholds so the feed does not become noise
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/destinations/{code}/risk | Current risk profile for a country, region or city |
| POST | /v1/trips/assess | Risk assessment for a specific itinerary |
| GET | /v1/events | Live disruption events with geography and travel impact scores |
| POST | /v1/portfolio/exposure | Which policies or travellers are affected by live events |
| GET | /v1/airports/{iata}/disruption | Disruption indicators for one airport or route |
| POST | /v1/monitoring | Register trips for monitoring with threshold-based alerts |
Request and response
illustrativeRequest
{
"trip": {
"trip_id": "trp_4410982",
"traveller_count": 2,
"segments": [
{ "from": "LHR", "to": "DPS", "depart": "2026-11-14T10:20:00Z", "carrier": "XX" },
{ "from": "DPS", "to": "LHR", "depart": "2026-11-28T18:05:00Z", "carrier": "XX" }
],
"accommodation_regions": ["ID-BA"]
},
"categories": ["security", "health", "weather", "transport"],
"monitor": true
}Response
{
"trip_id": "trp_4410982",
"overall_risk": { "score": 54, "band": "moderate" },
"by_category": {
"security": { "score": 31, "band": "low" },
"health": { "score": 38, "band": "low" },
"weather": { "score": 66, "band": "elevated",
"note": "Within regional wet season; localised flooding historically common mid-November" },
"transport": { "score": 71, "band": "elevated" }
},
"active_events": [
{
"event_id": "evt_88214",
"type": "volcanic_activity",
"location": { "name": "Mount Lewotobi region", "distance_to_dps_km": 412 },
"status": "elevated_alert",
"travel_impact": {
"score": 68,
"mechanism": "ash advisory affecting eastern approach corridors",
"affected_airports": ["DPS", "LOP"],
"historical_precedent": "2015 and 2017 episodes closed DPS for 2\u20134 days"
},
"updated_at": "2026-10-21T13:40:00Z"
}
],
"segment_flags": [
{ "segment": "LHR-DPS", "flag": "arrival_airport_event_exposure", "severity": "warning" }
],
"advisory_level": { "source": "official_government_advisory", "level": "exercise_caution",
"last_updated": "2026-08-02" },
"monitoring_registered": true
}Where the data comes from
| Official government travel advisories | Authoritative on security and entry requirements, published openly, and slow enough that they cannot be the only input |
| Aviation notices and airspace advisories | NOTAMs, volcanic ash advisories and airspace restrictions, which are the earliest formal signal of flight disruption |
| Meteorological agency data | Forecasts, severe weather warnings and tropical cyclone tracks from national meteorological services |
| Flight status and historical performance data | Delays, cancellations and on-time records by route and carrier, licensed from an aviation data provider |
| Public health notices | Outbreak and health advisory publications from international and national health authorities |
| Licensed news and event feeds | For civil unrest and localised disruption; this requires licensed content with permitted machine access, and the licence governs what may be redistributed |
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.
- Event geolocation and impact modelling as separate steps, because a major event far from any transport infrastructure a traveller will use is not a travel risk
- Travel impact scored on mechanism rather than severity — the question is whether it closes an airport, a road or a border, not how significant the event is in itself
- Itinerary matching at segment level against event geography, including the approach corridors and ground routes that country-level matching misses
- Historical precedent attached to event types where a comparable past event exists, since that is far more informative to a traveller than a severity label
- Seasonality baselines per destination so a normal wet season is not scored as an anomaly, which is a common failure in naive weather scoring
- Alert thresholding and deduplication, because a feed that reports every event is operationally identical to no feed at all
- Source reliability grading on unstructured event inputs, with official sources weighted above media reporting
- Portfolio matching performance tested at book scale, since exposure analysis is only useful if it completes while the event is still live
What it changes for the business
Known event exposure
When an airport closes you can tell within minutes how many in-force policies and travellers are affected.
Proactive assistance
Contacting affected travellers before they arrive at a closed airport changes both the claim and the experience of it.
Duty-of-care evidence
Itinerary-level monitoring with a retained alert record is what a duty-of-care obligation actually requires documenting.
Underwriting and pricing input
Destination and seasonal disruption patterns inform pricing and cover terms with measurement rather than impression.
How it fits into your product
How it embeds
- Trip assessment called at quote or booking, with optional monitoring registered for the trip duration
- Portfolio exposure endpoint called when an event escalates, returning affected policies for your operations team
- Webhooks and push notifications to traveller apps when a monitored trip becomes affected
- Map and timeline components for operations dashboards, or raw geometry for your own mapping
- Threshold configuration per customer segment, since a corporate programme and a leisure insurer want very different alert sensitivity
- Deployment inside your infrastructure where traveller itinerary data must not leave your environment
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 predict security incidents?
No. Terrorism, civil unrest onset and crime are not forecastable at the resolution that would be useful, and any product claiming otherwise is misrepresenting what it does. What we can do is detect and geolocate events quickly, assess their travel impact, and match them against itineraries. The security component of the risk score is a reflection of current and recent conditions, not a forecast.
How is this different from government advisories?
It includes them, and adds resolution they are not designed to provide. An advisory tells you the conditions in a country, updated occasionally. This tells you that an ash advisory affects the approach corridor to your traveller’s arrival airport on Thursday. Both matter, and the advisory remains the authority on security and entry requirements — we present it as such rather than replacing it with our own score.
Can we redistribute the event data to our customers?
Depends entirely on the source. Government advisories, meteorological warnings and aviation notices are public and reusable with attribution. Licensed news and flight status data usually permit display but restrict bulk redistribution or resale, and some prohibit caching. We map this source by source in discovery, and it genuinely shapes the design — sometimes a field can be shown to a traveller but not exported in an API response.
Will the alerting be noisy?
It is the main thing that goes wrong with these systems, so thresholding and deduplication are part of the build rather than a tuning exercise afterwards. Even so, the right sensitivity differs by audience: a corporate duty-of-care programme wants to know about things a leisure insurer does not. Thresholds are configurable per segment, and we would expect to spend real time tuning them with your operations team after launch.
How current is the event data?
Aviation and meteorological sources update within minutes and we poll them directly. Official advisories update on their own schedule, sometimes weeks apart, and the response carries their last-updated date so staleness is visible. Media-derived event detection is fast but less reliable, which is why source reliability is reported alongside the event rather than blended into a single score.
Related blueprints
Property Risk Scoring API
Flood, wildfire, storm and subsidence exposure scored at individual address level, for property underwriting and portfolio management.
Cyber Insurance Risk API
External attack surface measurement and security posture scoring from authorised, non-intrusive observation, for cyber underwriting and portfolio monitoring.
Vehicle Damage Estimation API
Damage detection, parts identification and a repair cost range from claim photographs, for motor insurers and claims administrators.
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.