Logistics & Supply Chain
Supplier Reliability Scoring API
Your supplier scorecard is a quarterly spreadsheet built from whatever the buyer remembered. The supplier that is about to fail is rarely the one it flags.
- Procurement teams
- Manufacturers
- Supply chain software vendors
- Retail buying teams
- 3PLs
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
Supplier performance management in most organisations is a quarterly review built from aggregated on-time percentages and a conversation. It has two structural problems. It is slow — a supplier deteriorating in March is discussed in July. And it is coarse, because one on-time number across all SKUs, plants and seasons averages away exactly the pattern that matters.
The data to do better is already in the ERP. Every purchase order has a promised date, a confirmed date and a receipt date. Every goods receipt has a quantity against an ordered quantity. Every quality rejection has a date and a reason code. Strung together per supplier, per site and per part, that is a detailed behavioural record which almost nobody reads at that resolution.
The forward-looking part needs more care. External disruption risk — a supplier's financial deterioration, concentration in a single plant, exposure to a region with labour unrest — draws on data that varies in quality and in how lawfully it can be used for a commercial decision. A reliability score built on your own transaction history is defensible. One that silently blends in a purchased risk feed of uncertain provenance is not.
Who buys this
Procurement teams, Manufacturers, Supply chain software vendors, Retail buying teams, 3PLs
What the API returns
What comes back
- Reliability score per supplier with component breakdown
- Punctuality analysis against promised and confirmed dates separately
- Quantity accuracy including short and over-shipment patterns
- Quality incident rates by reason code and trend
- Lead-time distribution per supplier and part, not just a mean
- Deterioration detection with change points, ahead of the quarterly review
- Concentration and single-source exposure across your supply base
- External disruption indicators with provenance and confidence stated
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/suppliers/{id}/score | Reliability score with components |
| GET | /v1/suppliers/{id}/punctuality | Delivery performance detail by site and part |
| GET | /v1/suppliers/{id}/leadtimes | Lead-time distributions |
| GET | /v1/alerts/deterioration | Suppliers showing recent deterioration |
| POST | /v1/suppliers/compare | Compare suppliers on the same measures |
| GET | /v1/exposure/concentration | Single-source and concentration exposure |
Request and response
illustrativeRequest
{
"supplier_id": "sup_3318",
"period": { "from": "2026-01-01", "to": "2026-10-21" },
"group_by": ["receiving_site", "part_family"],
"include": ["punctuality", "quality", "leadtimes", "external"]
}Response
{
"supplier_id": "sup_3318",
"name": "Example Components GmbH",
"score": 68,
"band": "watch",
"components": {
"punctuality": 61,
"quantity_accuracy": 88,
"quality": 72,
"lead_time_stability": 54,
"responsiveness": 79
},
"punctuality": {
"lines_received": 2841,
"on_time_vs_promised": 0.742,
"on_time_vs_confirmed": 0.891,
"mean_days_late": 2.4,
"p90_days_late": 9.0,
"worst_site": { "site": "plant_wroclaw", "on_time": 0.611 }
},
"lead_times": {
"median_days": 24,
"p90_days": 41,
"stability": "degrading",
"change_point": "2026-07-18"
},
"quality": {
"rejection_rate": 0.0124,
"top_reason": "dimensional_out_of_tolerance",
"trend": "worsening"
},
"external": [
{ "indicator": "single_plant_dependency", "level": "high",
"basis": "supplier_declared", "confidence": "medium" }
],
"alerts": [{ "code": "leadtime_change_point", "severity": "medium",
"detected": "2026-07-18" }]
}Where the data comes from
| Your ERP purchase order and receipt data | Promised, confirmed and actual dates with quantities — the backbone, and data you already own outright |
| Quality management records | Rejections, non-conformance reports and reason codes, which carry the signal that punctuality alone misses |
| Supplier master data | Sites, parts, incoterms and contractual lead times, so performance is measured against the right commitment |
| Supplier communications and confirmations | Order acknowledgements and reschedule requests, which distinguish a supplier that warns from one that goes silent |
| Company information sources | Registry and financial data where licensing permits its use for commercial assessment — provenance matters here |
| Public disruption signals | Reported plant incidents, regional events and transport disruptions, used as context with confidence stated |
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.
- Punctuality measured against promised and confirmed dates separately, because a supplier that reschedules early is a different risk from one that misses silently
- Lead-time distributions rather than means, since the p90 is what drives safety stock and the mean hides it
- Change-point detection on each component series, so deterioration is flagged when it starts rather than at quarter end
- Score components kept separate and visible, because a single number cannot support a procurement conversation
- Normalisation for order mix, volume and seasonality, so a supplier is not penalised for carrying your difficult parts
- Minimum-volume thresholds below which a score is withheld, since twelve order lines cannot support a reliability rating
- External indicators carried with explicit provenance and confidence, never silently folded into the headline score
- Validation against actual subsequent failures — stockouts, line stops, expedites — to check the score predicts something real
What it changes for the business
Earlier intervention
Change-point alerts surface a deteriorating supplier months before a quarterly scorecard would.
Better safety stock decisions
Lead-time distributions let inventory be set against observed variability rather than a contractual number.
Evidence for supplier conversations
Site and part level detail replaces an argument about whose spreadsheet is right.
Visible concentration risk
Single-source exposure across the supply base becomes a managed position rather than a discovery during a crisis.
How it fits into your product
How it embeds
- Pulls PO, receipt and quality data from your ERP on a schedule, or receives scheduled extracts
- Scorecard and trend components ready to embed in an existing procurement workspace
- Webhooks on deterioration alerts and score band changes into your workflow tools
- Batch scoring across a full supply base overnight
- Component weights configurable by your procurement function rather than fixed by us
- Deployment inside your infrastructure, which most manufacturers require for supplier data
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 score suppliers we have never bought from?
Barely, and we would be careful about claiming otherwise. With no transaction history there is no punctuality, quantity or quality record, and what remains is company information and public signals — useful for a first filter, not a reliability score. The API returns a clearly labelled pre-qualification view rather than pretending it is the same measure.
Does this use credit or financial risk data?
Only if you licence it and only where the licence permits use in commercial assessment. Where it is included it is carried as a separate indicator with its provenance attached, not blended into the reliability score. Mixing a purchased financial signal into a performance number makes the result impossible to explain to the supplier and hard to defend internally.
How do you avoid penalising a supplier for our own behaviour?
A good deal of apparent supplier lateness originates with late order placement, mid-order changes or unrealistic requested dates. The analysis separates these: performance against confirmed dates is reported alongside performance against promised dates, and orders placed inside the contractual lead time are flagged. Suppliers raise this objection immediately, and they are often right.
What volume do you need for a score?
Enough order lines for the components to be stable — in practice a few hundred receipts over a year for a reliable score, and considerably more before part-level detail means anything. Below the threshold the API withholds the score and says why rather than publishing a number built on noise.
Will the score predict a supplier failure?
It detects deterioration, which often precedes failure, and we validate it against your own history of stockouts and expedites to show whether it does so usefully. It will not anticipate a sudden event — a fire, an insolvency, an export ban — and a product claiming to would be selling a forecast it cannot make.
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.
Inventory Replenishment API
Reorder quantities, stockout risk and lead-time-aware replenishment planning, as the planning engine inside commerce or ERP 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.