Logistics & Supply Chain
Freight Rate Benchmarking API
You received three quotes for the same lane. Two are within five per cent of each other and one is forty per cent higher. Nobody in the room knows which is the market.
- Freight forwarders
- Shippers and procurement teams
- Freight marketplaces
- TMS vendors
- Logistics consultancies
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
Freight procurement runs on a remarkable amount of guesswork. A mid-sized shipper tenders a lane annually, gathers a handful of quotes, picks something near the middle and then spends twelve months with no idea whether the rate drifted away from the market. Spot buying is worse: a quote arrives, somebody judges it against what they paid last month, and that is the entire price discovery process.
Rate data is genuinely hard to assemble, which is why this gap persists. Rates are negotiated privately, bundled with surcharges and accessorials, quoted on different bases, and treated as commercially confidential by everyone holding them. Published indices exist for major trade lanes but are coarse, lagging and expensive, and they say nothing about a specific origin-destination pair with specific equipment.
The practical route is a contributory model. Participants contribute their own transaction data and receive benchmarks computed from the pool, under aggregation rules strong enough that no contributor's pricing can be recovered from the output. That shape works — it is how most private benchmarking markets operate — but the aggregation thresholds and the anti-reverse-engineering design are the product, not an afterthought.
Who buys this
Freight forwarders, Shippers and procurement teams, Freight marketplaces, TMS vendors, Logistics consultancies
What the API returns
What comes back
- Market rate estimate per lane, mode and equipment with a dispersion range
- Percentile position of a quote you have received against the pool
- Historical lane rate series with contributor counts attached
- All-in versus base-rate normalisation, with surcharges itemised
- Seasonality and directional imbalance effects per lane
- Rate movement alerts when a lane shifts beyond its usual range
- Comparable lane suggestions where a specific lane has too few observations
- Suppression metadata making clear when a benchmark is not publishable
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/benchmark | Market rate estimate for a lane and equipment type |
| POST | /v1/quotes/assess | Position a received quote against the market |
| GET | /v1/lanes/{lane_id}/history | Historical rate series for a lane |
| POST | /v1/contribute | Contribute transaction data into the benchmarking pool |
| GET | /v1/lanes/{lane_id}/seasonality | Seasonal and directional patterns |
| GET | /v1/alerts/movements | Lanes that have moved beyond their normal range |
Request and response
illustrativeRequest
{
"lane": { "origin": "ESBCN", "destination": "DEHAM", "mode": "road_ftl" },
"equipment": "curtainside_13_6m",
"basis": "all_in",
"currency": "EUR",
"quote_received": 1480.00,
"as_of": "2026-10-22"
}Response
{
"lane": { "origin": "ESBCN", "destination": "DEHAM", "mode": "road_ftl" },
"equipment": "curtainside_13_6m",
"basis": "all_in",
"currency": "EUR",
"market": {
"p25": 1265.00,
"p50": 1372.00,
"p75": 1498.00,
"observations": 418,
"contributors": 11,
"window_days": 30,
"publishable": true
},
"quote_assessment": {
"quote": 1480.00,
"percentile": 72,
"verdict": "above_median_within_range",
"vs_p50_pct": 7.9
},
"components": {
"base_rate_p50": 1184.00,
"fuel_surcharge_p50": 142.00,
"tolls_p50": 46.00
},
"context": {
"direction_imbalance": "headhaul",
"seasonal_effect_pct": 4.1,
"movement_30d_pct": -2.6
},
"method": { "aggregation": "min_5_contributors_min_20_observations",
"outlier_rule": "winsorised_at_2_5_pct" }
}Where the data comes from
| Contributory transaction data | Actual booked rates from participants, which is the only source with real depth at lane level |
| Your own freight invoices | Your paid rates, parsed and normalised — most shippers hold more usable rate history than they realise |
| Published freight indices | Licensed index data for major trade lanes, useful as an anchor and a sanity check rather than as the benchmark |
| Fuel price data | Diesel and bunker prices by region, since surcharge mechanisms are formula-driven and separable from base rate |
| Toll and tariff schedules | Published road tolls and port charges, which let an all-in rate be decomposed consistently |
| Lane and location reference data | Port, terminal and postcode geography so lanes are matched rather than approximately matched |
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.
- Normalisation of every rate to a canonical basis before pooling, since all-in and base-plus-surcharge quotes are not comparable
- Minimum contributor and observation thresholds below which no benchmark is published at all
- Winsorising of extreme rates so one unusual transaction cannot move a published percentile
- Explicit testing that a contributor's own rates cannot be recovered by differencing overlapping queries or time windows
- Lane hierarchy with fallback to corridor and region level when a specific pair is too thin, labelled as such in the response
- Surcharge decomposition using published fuel and toll formulas, which makes base rates comparable across periods
- Directional and seasonal effects estimated per lane, because headhaul and backhaul are genuinely different markets
- Ongoing monitoring of pool composition, since a benchmark dominated by two contributors is not a market measure
What it changes for the business
Price discovery in procurement
A quote can be positioned against the market before it is accepted rather than after the invoice.
Defensible tender decisions
Procurement can show why a rate was accepted, which matters when the choice is questioned internally.
Contract drift detection
Movement alerts show when a contracted rate has quietly become expensive relative to the spot market.
A sellable layer for marketplaces
A freight platform that can tell participants where a quote sits is more useful than one that only lists them.
How it fits into your product
How it embeds
- Contribute by API, scheduled file drop or invoice parsing, depending on where your rate data lives
- Inline assessment endpoints fast enough to sit next to a quote in your TMS or procurement screen
- Webhooks on lane movement beyond a configured threshold
- Batch benchmarking across a full tender or contracted lane portfolio
- Benchmark components and lane history charts ready to embed
- Contribution and consumption entitlements managed per participant, so access can be tied to contribution
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 weeksDiscovery 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 our rates be visible to competitors?
No, and the design exists to make that true rather than to assert it. Minimum contributor counts, minimum observation counts, winsorising and explicit differencing tests all guard against recovery of individual pricing. Where a lane is too thin to meet those thresholds, nothing is published — the API returns unpublishable rather than a number computed from two contributors.
How good is coverage outside major lanes?
Thin, honestly. Major road corridors and container trades build depth quickly. A specific regional pair with specialist equipment may never have enough observations, in which case the API falls back to a corridor-level benchmark and labels it as a fallback. A benchmark that silently widens its geography to look confident is worse than no benchmark.
Is this a forecast of where rates are going?
No. It measures where the market has been and where it is now, with movement over recent windows. Freight rate forecasting is a separate and much harder problem driven by capacity, fuel and demand cycles, and we would not fold a weak forecast into a benchmark that is otherwise a measurement.
What if we have no rate history to contribute?
You can consume benchmarks without contributing, though most pool arrangements price that differently and some restrict depth. Your freight invoices are usually a better starting point than people expect — two years of paid invoices parsed and normalised is a substantial contribution even if it was never structured data.
Can you benchmark air and ocean as well as road?
Yes in principle, with different normalisation. Ocean needs careful handling of surcharges, equipment imbalance and contract-versus-spot distinction; air needs chargeable weight treated properly. Both are feasible, both need their own normalisation work, and we would scope them as separate phases rather than claiming one model covers all modes.
Related blueprints
Supplier Reliability Scoring API
Punctuality, quality incident and disruption risk scoring per supplier, for procurement and supply chain software.
Carbon Emissions Calculation API
Shipment and route emissions figures with the method and data quality attached, for logistics and reporting software.
Delivery Time Prediction API
Estimated delivery windows and delay probabilities per shipment, as the promise engine behind a commerce or carrier product.
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.