Logistics & Supply Chain
Inventory Replenishment API
Reorder points are usually set once, by somebody who has since left, and then carried forward because nobody wants to break them.
- Retailers and e-commerce operators
- Wholesalers and distributors
- ERP and inventory software vendors
- 3PLs with fulfilment
- Manufacturers
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
Replenishment in most organisations runs on static reorder points and fixed order quantities that were reasonable when they were set and have not been revisited since. Demand moved, lead times lengthened, the supplier changed its minimum order, and the parameters stayed where they were. The symptoms are familiar: a warehouse holding eleven months of one SKU and stocking out of another every quarter.
The arithmetic that fixes this is not new. Safety stock against demand and lead-time variability, reorder points derived from the distribution rather than the mean, order quantities balancing holding cost against ordering cost and supplier constraints. It has been textbook material for decades. What stops it being applied is that it needs a demand forecast per SKU and location, a lead-time distribution per supplier and part, and both of those maintained continuously rather than calculated once.
Lead time is the part most systems get badly wrong. They hold a single contractual number — 21 days — when the actual distribution has a median of 24 and a ninetieth percentile of 41. Safety stock computed against the contractual figure is structurally too low, and the resulting stockouts get blamed on demand volatility rather than on the parameter that caused them.
Who buys this
Retailers and e-commerce operators, Wholesalers and distributors, ERP and inventory software vendors, 3PLs with fulfilment, Manufacturers
What the API returns
What comes back
- Recommended reorder quantity per SKU and location
- Stockout probability over a configurable horizon
- Reorder point and safety stock derived from demand and lead-time distributions
- Lead-time distributions per supplier and part rather than contractual figures
- Service-level targeting, so cover is set by a stated policy not by habit
- Order consolidation respecting minimum order quantities and container fill
- Excess and obsolescence flags for stock that will not sell through
- Explanation per recommendation, naming the drivers of the quantity
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/skus/{id}/replenishment | Recommendation for one SKU and location |
| POST | /v1/replenishment/plan | Replenishment plan across a SKU and location set |
| GET | /v1/skus/{id}/stockout-risk | Stockout probability over a horizon |
| GET | /v1/suppliers/{id}/leadtimes | Lead-time distribution per supplier and part |
| POST | /v1/orders/consolidate | Group recommendations into orders under constraints |
| GET | /v1/excess | Stock flagged as excess or at obsolescence risk |
Request and response
illustrativeRequest
{
"location": "dc_birmingham",
"sku_set": "fast_moving",
"policy": { "target_service_level": 0.97, "review_period_days": 7 },
"constraints": { "respect_moq": true, "container_fill_target": 0.9,
"max_order_value": 250000 },
"horizon_days": 90
}Response
{
"location": "dc_birmingham",
"generated_at": "2026-10-22T02:00:00Z",
"policy": { "target_service_level": 0.97, "review_period_days": 7 },
"recommendations": [
{
"sku": "SKU-3301",
"on_hand": 1840,
"on_order": 0,
"demand_forecast_30d": { "p50": 2210, "p90": 2780 },
"lead_time_days": { "p50": 24, "p90": 41, "source": "observed_18_receipts" },
"reorder_point": 3120,
"safety_stock": 910,
"recommended_order_qty": 4800,
"stockout_probability_90d": 0.031,
"drivers": [
{ "factor": "lead_time_p90_above_contract", "effect": "+480 units safety stock" },
{ "factor": "moq_rounding", "effect": "+300 units order quantity" }
]
},
{
"sku": "SKU-7719",
"on_hand": 9420,
"demand_forecast_30d": { "p50": 310, "p90": 480 },
"months_of_cover": 30.4,
"recommended_order_qty": 0,
"flags": ["excess_stock", "obsolescence_risk_medium"]
}
],
"consolidation": { "orders": 3, "container_fill": [0.92, 0.88, 0.41] }
}Where the data comes from
| Your sales and shipment history | Demand history at SKU and location level, which is the foundation of every number in the output |
| Inventory position data | On hand, on order, allocated and in transit — getting in-transit wrong is a common and expensive source of double ordering |
| Purchase order receipt history | Order and receipt dates, which is how a real lead-time distribution replaces the contractual figure |
| Supplier terms | Minimum order quantities, order multiples, container capacities and pricing breaks, all of which constrain the answer |
| Product master data | Shelf life, substitutability, lifecycle stage and classification, needed for obsolescence and substitution logic |
| Promotion and event calendars | Planned promotions and seasonal events, since demand history alone will not anticipate a campaign nobody told the model about |
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.
- Demand forecasting at SKU and location level with intermittency handled properly, because a large share of SKUs sell in sporadic single units
- Lead-time distributions estimated from observed receipts, with contractual figures used only as a prior where receipts are too few
- Safety stock derived from the convolution of demand and lead-time uncertainty rather than from a demand-only formula
- Service level as an explicit policy input per SKU class, so the business sets cover rather than inheriting it
- Order quantity optimisation under real constraints — MOQ, multiples, container fill, budget — since an unconstrained economic quantity is unorderable
- Consolidation across SKUs into supplier orders, which frequently changes the per-SKU answer and cannot be done SKU by SKU
- Excess and obsolescence detection from cover against lifecycle stage, flagged early enough to act on
- Backtesting against held-out history reporting both service level achieved and inventory held, because improving one at the cost of the other is not a result
What it changes for the business
Fewer stockouts at the same stock level
Safety stock set against real lead-time variability puts cover where it is actually needed.
Working capital released
Excess flags surface the SKUs carrying months of unnecessary cover.
Explainable recommendations
A buyer who can see why the quantity is 4,800 will place the order rather than override it.
Policy instead of habit
Service levels become a stated business decision per SKU class rather than an accident of old parameters.
How it fits into your product
How it embeds
- Pulls sales, inventory and PO data from your ERP or commerce platform on a schedule
- Overnight planning runs across the full SKU and location set, with on-demand single-SKU endpoints for buyers
- Recommendations returned for buyer approval, with optional PO draft creation once the process is trusted
- Webhooks on stockout risk crossing a threshold and on new excess flags
- Policy configuration per SKU class, set by your planning function
- Deployment inside your infrastructure where commercial 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
Will it place orders automatically?
Only if you ask, and we would start with recommendations for approval. Automatic ordering is reasonable for stable, high-volume, low-value lines once the recommendations have been watched for a few cycles. Switching it on across a full catalogue from day one tends to produce one expensive mistake and a permanent loss of confidence in the system.
How does it handle new products with no history?
Badly, in the sense that no method handles it well. The options are a comparable-product analogue, a planner-supplied forecast, or a deliberately cautious launch quantity with frequent review. The API supports all three and labels the recommendation as analogue-based or planner-supplied, so nobody mistakes it for a forecast from data.
What about promotions?
They have to be told to the system. Demand history will not anticipate a campaign that has not happened, and a model that infers promotions from past spikes will apply them at the wrong times. Planned promotions are an input, and a promotion that nobody enters will cause a stockout no amount of modelling prevents.
Can it work with our contractual lead times instead of observed ones?
It can, and we would advise against it. Observed receipt distributions are almost always wider than the contractual figure, and safety stock computed on the contract is systematically too low. If you prefer contractual figures for a supplier, the API will use them and flag the recommendation as using a contractual lead time so the choice is visible.
Does it cover multi-echelon networks?
Single-echelon planning per location is the standard build and solves most of the problem. True multi-echelon optimisation across a DC and store network is a materially harder piece of work, worth doing when the network genuinely has dependent echelons, and we would scope it as a separate phase rather than quietly approximating it.
Related blueprints
Supplier Reliability Scoring API
Punctuality, quality incident and disruption risk scoring per supplier, for procurement and supply chain software.
Delivery Time Prediction API
Estimated delivery windows and delay probabilities per shipment, as the promise engine behind a commerce or carrier product.
Route Risk Intelligence API
Disruption, weather exposure, security and delay indicators along a planned route, for transport planning and freight 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.