Logistics & Supply Chain
Route Risk Intelligence API
Route planning optimises for distance and cost. The expensive part of a journey is usually the thing nobody planned for.
- Carriers and hauliers
- Freight forwarders
- Transport management software
- Cargo insurers
- Shippers with own fleets
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
A transport planner choosing between two routings is handed distance, estimated duration and toll cost. What they are not handed is that one of them crosses a pass that closes for snow six days a year, passes two border points with unpredictable queues, and runs through a corridor with a cargo theft problem on Sunday nights. Those differences do not show up in a cost comparison and they are where the losses are.
Each of those risks has data behind it, in different shapes. Road authority feeds publish closures and works. Meteorological services publish forecasts that matter for specific vehicle types on specific gradients. Border waiting times are published by some authorities and nowhere by others. Cargo crime data exists but is fragmentary, often reported voluntarily, and uneven between countries in a way that makes raw comparison misleading.
The honest framing is exposure rather than prediction. We are not forecasting that a particular lorry will be robbed or stuck. We are measuring what a route is exposed to, how often those conditions have occurred historically, and what is currently active on it — which is enough to choose between routings, price a lane properly and decide where a secure parking stop belongs.
Who buys this
Carriers and hauliers, Freight forwarders, Transport management software, Cargo insurers, Shippers with own fleets
What the API returns
What comes back
- Route-level risk profile with contributions by category
- Active disruptions along a route: closures, works, restrictions and incidents
- Weather exposure translated into operational terms by vehicle type
- Border and crossing wait time estimates where authorities publish them
- Security exposure by segment, from reported cargo crime, with data-quality caveats
- Historical reliability of a lane, including seasonal closure probability
- Segment-level detail so a planner can see which stretch carries the risk
- Alternative routing comparison on the same risk measures
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/routes/risk | Risk profile for a planned route or waypoint list |
| POST | /v1/routes/compare | Compare alternative routings on the same measures |
| GET | /v1/segments/{id}/risk | Risk detail for one road segment |
| GET | /v1/disruptions | Active disruptions within an area or along a corridor |
| GET | /v1/crossings/{id}/wait | Current and typical wait times at a crossing |
| WS | /v1/stream | Push new disruptions affecting monitored routes |
Request and response
illustrativeRequest
{
"waypoints": [
{ "lat": 45.4642, "lon": 9.1900, "role": "origin" },
{ "lat": 47.3769, "lon": 8.5417, "role": "via" },
{ "lat": 50.1109, "lon": 8.6821, "role": "destination" }
],
"vehicle": { "type": "articulated_hgv", "height_m": 4.0, "weight_t": 40,
"adr_class": null },
"departure": "2026-12-04T05:00:00Z",
"include": ["weather", "security", "crossings", "history"]
}Response
{
"route_risk": { "score": 64, "band": "elevated" },
"distance_km": 842,
"categories": {
"weather": 71,
"infrastructure": 48,
"crossings": 62,
"security": 44,
"congestion": 55
},
"active_disruptions": [
{ "segment_id": "seg_ch_a2_204", "type": "lane_closure",
"detail": "Northbound lane closure, Gotthard approach",
"from": "2026-12-01", "to": "2026-12-08", "delay_minutes_typical": 35 }
],
"weather_exposure": [
{ "segment_id": "seg_ch_a2_211", "hazard": "snow_on_gradient",
"forecast_probability": 0.38,
"operational_effect": "winter equipment required; closure possible",
"historical_closure_days_per_year": 6.2 }
],
"crossings": [
{ "crossing_id": "xng_ch_de_basel", "typical_wait_minutes": 24,
"p90_wait_minutes": 95, "current_wait_minutes": 31 }
],
"security": [
{ "segment_id": "seg_de_a5_077", "exposure": "elevated",
"basis": "reported_incidents_3y", "incidents": 41,
"caveat": "voluntary reporting; cross-country comparison unreliable" }
],
"nearest_secure_parking": [{ "name": "Rastplatz example", "km_from_origin": 611,
"rating": "class_3" }]
}Where the data comes from
| Road authority feeds | National and regional closure, works and restriction data, generally open and the most reliable disruption source |
| Meteorological services | Forecasts and warnings from national providers, plus historical records for the seasonal closure statistics |
| Border and crossing data | Published wait times where an authority provides them — coverage is uneven and the gaps are real |
| Cargo crime reporting | Industry and police-reported incident data, used under agreement, with known reporting bias between jurisdictions |
| Routing and road network data | Segment geometry, gradients, restrictions and vehicle-class limits, so a route maps onto segments correctly |
| Your own journey history | Optional — your telematics and delay records calibrate the model to how your fleet actually performs on these lanes |
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.
- Routes decomposed to road segments so risk is attributed to a stretch rather than averaged over 800 kilometres
- Weather hazards translated into vehicle-specific operational effects, since a gradient with snow means something different for a 40-tonne articulated vehicle than for a van
- Seasonal closure probabilities estimated from multi-year historical records rather than from current forecasts alone
- Crossing wait distributions modelled with their tails exposed, because the p90 wait is the one that breaks a driver's hours
- Security exposure normalised for reporting intensity, with an explicit unreliability flag where cross-jurisdiction comparison is not defensible
- Exposure framing throughout — no claim that a specific journey will be disrupted, only what it is exposed to and how often that has occurred
- Calibration against your own journey outcomes where telematics history is supplied, reported per corridor
- Source-availability monitoring, since authority feeds change format and disappear without notice
What it changes for the business
Routing decisions with risk priced in
A planner can choose a longer routing knowingly rather than discover the pass is shut at 3am.
Better lane pricing
Exposure data supports a defensible surcharge on genuinely difficult lanes instead of a flat margin.
Driver hours protection
Crossing wait tails and closure probabilities feed planning that does not routinely blow through rest rules.
Insurance and claims support
Documented exposure at the time of planning is useful evidence in both underwriting and disputes.
How it fits into your product
How it embeds
- POST a waypoint list or a routing from your existing TMS and receive a risk profile back
- WebSocket and webhooks for disruptions appearing on monitored routes after dispatch
- Comparison endpoints so alternatives can be scored inside your existing planning screen
- Segment-level responses that map onto your own network references
- Batch scoring for a planned week of journeys overnight
- Deployment inside your infrastructure where journey plans are commercially sensitive
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 cargo theft?
No, and we would refuse to build something that claimed to. Reported cargo crime data is voluntary in most jurisdictions, uneven between countries, and sparse at segment level. What it supports is an exposure measure — this corridor has had many more reported incidents than comparable corridors — with an explicit warning that comparisons across borders reflect reporting practice as much as reality. Anything stronger would be a false precision with real consequences for drivers.
How far ahead is the weather component useful?
Operationally useful inside about 72 hours. Beyond that the forecast skill for the specific hazards that matter — snow on a gradient, crosswind on an exposed bridge — falls away, and the API switches to historical seasonal probability, which it labels as such. We do not blend them into one number that looks like a forecast.
Do you have border wait times everywhere?
No. Some authorities publish them, some publish them unreliably, and some publish nothing. Where there is no source the API returns a historical distribution if we have one and unknown if we do not. We would rather show a gap than produce a plausible number with nothing behind it.
Does this replace our routing engine?
No. It scores a route your routing engine produced. Combining risk into the optimisation itself is possible as a second phase, but the first useful version compares the candidate routings you already generate, which is where most of the decision value sits.
How do you handle dangerous goods?
ADR class restrictions, tunnel categories and permitted routing are part of the segment reference data, so a route can be checked for compliance with the vehicle's classification. That is a restriction check against published rules, not a safety assessment, and the legal responsibility for compliant routing stays with the operator.
Related blueprints
Shipment Exception Prediction API
Early warnings for shipments heading towards delay, loss or a missed handoff, as the exception engine inside logistics software.
Delivery Time Prediction API
Estimated delivery windows and delay probabilities per shipment, as the promise engine behind a commerce or carrier product.
Freight Rate Benchmarking API
Market rate estimates and historical lane pricing, so shippers and forwarders can tell a fair quote from an expensive one.
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.