Logistics & Supply Chain
Delivery Time Prediction API
The delivery date you show at checkout is a commercial promise. Most of them are produced by adding a fixed number of days to today.
- E-commerce platforms
- Carriers and couriers
- 3PLs
- Marketplaces
- Order management software
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
The estimate shown at checkout does more work than any other number in the order flow. It converts the sale, it sets the expectation, and it generates the support ticket when it is wrong. Yet in most systems it is a static transit table — three to five working days for this service to this postcode — that ignores the warehouse's actual cut-off, the carrier's current performance on that lane, the time of year, and whether the item is in the right facility.
The result is a promise that is both too wide to be useful and too optimistic to be reliable. Customers who are told three to five days and receive the parcel on day six do not credit the system for the three; they open a ticket. Meanwhile a conservative estimate costs conversion on exactly the orders where the parcel would have arrived tomorrow.
Better estimates come from the operation's own event history rather than from the carrier's published service level. Every scan event in the last two years is a labelled observation: this parcel, this origin, this destination, this service, this day of week, this volume condition, arrived after this long. That is a well-posed prediction problem, and the main difficulty is the event data being messy, inconsistently timestamped and full of gaps.
Who buys this
E-commerce platforms, Carriers and couriers, 3PLs, Marketplaces, Order management software
What the API returns
What comes back
- Predicted delivery date with a distribution, not a single day
- Promise windows calibrated to a chosen service level rather than to the median
- Delay probability against a stated promise date
- Remaining-transit re-estimation at each scan event
- Cut-off aware dispatch timing, including the effect of ordering an hour from now
- Lane and service performance history behind each estimate
- Driver attribution: which conditions widened or shifted this estimate
- Confidence flags for new lanes, new carriers and unusual conditions
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/predict | Predicted delivery window for a prospective or placed order |
| POST | /v1/predict/batch | Predictions across a batch of orders or shipments |
| GET | /v1/shipments/{id}/eta | Current estimate for an in-flight shipment |
| POST | /v1/promise | Promise date at a chosen confidence level |
| GET | /v1/lanes/{origin}-{destination}/performance | Historical performance for a lane and service |
| POST | /v1/events | Post scan events for continuous re-estimation and calibration |
Request and response
illustrativeRequest
{
"order": {
"origin_facility": "wh_leeds_1",
"destination_postcode": "08019",
"destination_country": "ES",
"service": "standard_road",
"carrier": "crr_7",
"ordered_at": "2026-10-22T16:42:00Z",
"items": [{ "sku": "SKU-3301", "qty": 2, "in_stock_at_origin": true }]
},
"promise_confidence": 0.9
}Response
{
"predicted_delivery": {
"p50": "2026-10-27",
"p90": "2026-10-29",
"distribution": [
{ "date": "2026-10-26", "probability": 0.14 },
{ "date": "2026-10-27", "probability": 0.41 },
{ "date": "2026-10-28", "probability": 0.26 },
{ "date": "2026-10-29", "probability": 0.11 },
{ "date": "2026-10-30+", "probability": 0.08 }
]
},
"promise": { "date": "2026-10-29", "confidence": 0.9 },
"dispatch": {
"cutoff_at": "2026-10-22T17:30:00Z",
"makes_today_cutoff": true,
"if_missed_adds_days": 1
},
"drivers": [
{ "factor": "lane_performance_recent", "effect_days": 0.0 },
{ "factor": "carrier_backlog_signal", "effect_days": 0.4 },
{ "factor": "destination_remote_flag", "effect_days": 0.6 }
],
"lane": { "observations": 11420, "on_time_rate_90d": 0.934 },
"confidence": "high"
}Where the data comes from
| Your carrier scan events | Collection, hub, out-for-delivery and delivery scans — the labelled history the whole model is built on |
| Your order and dispatch records | Order timestamps, picking times and actual dispatch, so the warehouse portion of transit is modelled rather than assumed |
| Carrier service definitions and cut-offs | Published service levels and collection times, used as structure rather than as the prediction |
| Postcode and address reference data | Remoteness, delivery-area surcharges and known difficult zones, which shift transit materially |
| Calendar data | Public holidays by country and region, plus carrier non-operating days, which cause most of the large misses |
| Weather and disruption signals | Severe weather and known network disruptions, useful for the in-flight re-estimation more than at checkout |
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.
- Survival-style modelling of remaining transit time, so an estimate can be revised sensibly at each scan rather than recomputed from scratch
- Quantile outputs with promise dates derived at a caller-chosen confidence, because the right service level is a commercial decision not a modelling one
- Warehouse and carrier phases modelled separately, since cut-off and pick-time effects behave nothing like line-haul variability
- Explicit holiday and non-operating-day handling in the calendar layer rather than learned implicitly, which never generalises to next year
- Lane pooling with hierarchical priors so a thin lane borrows from similar lanes instead of returning nonsense
- Peak-period features, because November and December transit distributions differ enough to warrant their own treatment
- Calibration monitoring by lane, carrier and service, with alerting when realised on-time rates drift from the promised confidence
- Backtesting on held-out historical periods including at least one peak season, reported per lane rather than in aggregate
What it changes for the business
Honest promises
A promise set at a measured confidence level means the stated date is met at roughly that rate.
Conversion from precision
A tight, credible window on fast lanes converts better than a defensive three-to-five-day range.
Fewer where-is-my-order tickets
Most of that traffic comes from estimates that were wrong, not from parcels that were late.
Carrier accountability
Lane-level performance history turns a carrier review from an argument into a data exercise.
How it fits into your product
How it embeds
- Checkout-latency endpoint sized for inline use, with batch endpoints for order books and re-estimation runs
- Scan events posted as they arrive so in-flight estimates stay current without polling
- Webhooks when a shipment's delay probability crosses a threshold, for proactive customer messaging
- Promise confidence configurable per channel, so a marketplace listing and your own site can differ
- Lane performance endpoints for your carrier management and procurement teams
- Deployment inside your infrastructure where order and address 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 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
How much history do you need before this beats a transit table?
Roughly six months of scan events on a lane, or a few thousand observations, before the lane-specific model is clearly better. Below that it leans on pooled priors and will perform about as well as a well-maintained transit table — which is to say the gain is real but it arrives with volume, not on day one.
Can you predict a specific delivery time of day?
Only where the carrier emits the data that makes it possible, which in practice means some last-mile networks and not others. For the rest, a time-of-day estimate would be invented. The API returns a time window only when the underlying events support one, and a date otherwise.
What happens during peak season?
Transit distributions widen and shift, and the model handles that with peak features provided it has seen at least one prior peak. A first peak after launch is the weakest point in the deployment, and we would widen promises deliberately through it rather than discover the calibration problem from customer complaints.
Does this work for international and customs-cleared shipments?
Partly. The controllable portions — warehouse, line-haul, final delivery — model well. Customs dwell is lumpy, occasionally very long, and driven by factors that are not visible in scan data. We model it as a separate phase with a heavy tail and we are explicit that the tail is wide rather than pretending otherwise.
Will it tell us a carrier is underperforming?
Yes, and it is one of the more valuable side effects. Lane-level performance against the carrier's own published service level is computed from your scan data, and the comparison is frequently uncomfortable for the carrier. We would report it as measured rather than softening it.
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.
Route Risk Intelligence API
Disruption, weather exposure, security and delay indicators along a planned route, for transport planning and freight software.
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.