Insurance & Claims
Vehicle History Intelligence API
A vehicle’s history is recorded in six different places by organisations that have no reason to talk to each other. The buyer, the insurer and the lender all need it in one answer.
- Motor insurers
- Used vehicle marketplaces
- Dealers
- Vehicle finance providers
- Fleet remarketing teams
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 records exist. Registration authorities hold ownership and status. Insurers record total losses and category write-offs. Inspection and roadworthiness testing regimes capture odometer readings at known dates. Finance houses register outstanding interests. Manufacturers hold recall and service data. What does not exist is any single place where these agree, and the gaps between them are exactly where misrepresentation happens.
Mileage discrepancy is the clearest example. A vehicle with an odometer reading lower than a previously recorded one has either had a cluster replaced, been clocked, or been recorded in error. Detecting it requires nothing more than a time-ordered series of readings from inspection records — and that detection is impossible if you only hold the current reading, which is what most buyers are looking at.
The constraint on building this is not technical, it is contractual. Nearly every valuable source here is licensed rather than open, and the licences are specific about permitted use: some allow a per-vehicle lookup to a consumer, some allow use only in underwriting, almost none allow building a resellable database. A vehicle history product is therefore shaped by its data agreements more than by its architecture, and anyone who tells you otherwise has not read the terms.
Who buys this
Motor insurers, Used vehicle marketplaces, Dealers, Vehicle finance providers, Fleet remarketing teams
What the API returns
What comes back
- Vehicle identity resolved from VIN or registration, with specification and variant detail
- Ownership history: number of keepers and change dates, within what the licence permits
- Write-off and total loss records with category and recorded date
- Mileage history as a time-ordered series, with discrepancies flagged and quantified
- Outstanding finance and registered interests where the register is accessible
- Theft and stolen-vehicle status against official registers
- Recall status and outstanding safety campaigns
- Per-field provenance and licence scope, so you know what you may show and to whom
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/vehicles/{identifier} | Full history record for a VIN or registration |
| GET | /v1/vehicles/{identifier}/mileage | Mileage series with discrepancy analysis |
| GET | /v1/vehicles/{identifier}/writeoff | Write-off and total loss records |
| GET | /v1/vehicles/{identifier}/finance | Registered finance interests, where permitted |
| POST | /v1/vehicles/batch | Batch lookup for portfolio or stock checking |
| GET | /v1/coverage | Source coverage and permitted uses by country and field |
Request and response
illustrativeRequest
{
"identifier": "WVWZZZ1KZBW123456",
"identifier_type": "vin",
"country": "GB",
"fields": ["identity", "ownership", "writeoff", "mileage", "finance", "recalls"],
"use_case": "consumer_vehicle_check"
}Response
{
"identifier": "WVWZZZ1KZBW123456",
"identity": {
"make": "Volkswagen", "model": "Golf", "variant": "1.4 TSI Match",
"first_registered": "2011-06-14", "fuel": "petrol", "colour_current": "silver",
"colour_changes": 1
},
"ownership": { "keepers_recorded": 4, "last_change": "2023-09-02",
"licence_scope": "count_and_dates_only" },
"writeoff": {
"records": [
{ "category": "N", "recorded_on": "2019-04-11",
"source": "insurance_industry_register",
"note": "Non-structurally damaged, repairable; vehicle returned to road" }
]
},
"mileage": {
"series": [
{ "date": "2021-05-20", "reading": 71420, "source": "roadworthiness_test" },
{ "date": "2022-05-28", "reading": 82910, "source": "roadworthiness_test" },
{ "date": "2023-06-02", "reading": 64200, "source": "roadworthiness_test" },
{ "date": "2024-06-10", "reading": 97840, "source": "roadworthiness_test" }
],
"discrepancy": {
"detected": true,
"between": ["2022-05-28", "2023-06-02"],
"reduction_miles": 18710,
"assessment": "Reading decreased between consecutive tests; consistent with cluster replacement or odometer adjustment"
}
},
"finance": { "interests_registered": 0, "register_checked": "asset_finance_register" },
"stolen": { "status": "no_marker", "register_checked": "police_vehicle_register" },
"recalls": { "outstanding": 1,
"detail": "Fuel pump campaign, issued 2023-11, no completion recorded" },
"provenance": [
{ "field": "writeoff", "source": "insurance_industry_register",
"permitted_display": "category_and_date", "resale_permitted": false }
],
"checked_at": "2026-10-21T14:30:00Z"
}Where the data comes from
| National vehicle registration authority | Ownership, status and specification data; access and permitted use are tightly defined and differ by country and by use case |
| Insurance industry write-off registers | Total loss and damage category records contributed by insurers; membership terms govern who may query and what may be shown |
| Roadworthiness and inspection records | Periodic test results including odometer readings at known dates — the backbone of mileage verification wherever such a regime exists |
| Asset finance registers | Registered interests in vehicles, where a searchable register exists and permits third-party queries |
| Police and stolen vehicle registers | Theft markers, generally accessible only to authorised parties under defined conditions |
| Manufacturer recall data | Published safety campaigns, with completion status available in some markets and not others |
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.
- Identity resolution from VIN and registration with variant decoding, since specification differences within a model change both valuation and parts
- Mileage series reconciliation across sources with explicit discrepancy classification — decrease, implausible accumulation rate, or long gap with no reading
- Cross-source conflict detection and resolution rules, because registration data, inspection records and insurer records disagree more often than you would expect
- Per-field licence scope carried through to the response, so your product can enforce at render time what each agreement permits
- Plausibility checks on mileage accumulation against vehicle age, type and recorded usage, which catches adjustments that do not produce an outright decrease
- Provenance recorded per field with source and read date, since a vehicle history claim that cannot be sourced cannot be defended in a dispute
- Caching policy derived from each source’s terms rather than from performance preference — several sources prohibit retention beyond the immediate query
- Coverage and freshness monitoring per source and country, because these registers have real availability gaps and silent failures
What it changes for the business
Underwriting accuracy
Write-off and mileage history at quote prices the vehicle actually in front of you rather than the one described.
Reduced misrepresentation
Discrepancies found at underwriting are a pricing decision; found at claim they are a dispute with a policyholder.
Marketplace trust
A sourced history check attached to a listing is one of the few things that measurably changes used-vehicle buyer behaviour.
Finance security
Registered interest and write-off checks protect a lender against advancing against a vehicle that is not what it appears.
How it fits into your product
How it embeds
- Single lookup at quote, listing creation or finance application, with batch endpoints for stock and portfolio checking
- Licence scope returned per field so your front end can show, redact or omit according to the agreement rather than by convention
- Consumer-facing report rendering where the licence permits consumer display, which is a specific permission rather than a general one
- Webhooks on new records against a monitored vehicle, useful for finance books and fleet remarketing
- Coverage endpoint so your flow can route unsupported countries to a manual process rather than returning an empty record
- Deployment inside your infrastructure where source agreements require data to remain within your environment
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 cover every country?
No. Coverage depends entirely on whether a country has the relevant registers and whether they are accessible to a commercial party. Some markets have excellent inspection records with odometer readings and an industry write-off register; others have no accessible mileage history at all. The coverage endpoint states field-level availability per country, and we would rather tell you a field is unavailable than return a confident empty answer.
Can we build a database and resell lookups?
Usually not, and this is the constraint that most often reshapes the product. Registration authorities, insurance write-off registers and finance registers typically license per-query access for defined purposes, prohibit bulk extraction, and restrict onward resale. Several prohibit retaining results beyond the immediate query. We read every agreement in discovery and design the caching and architecture around what they actually permit — which sometimes means the product is a routed lookup rather than a dataset you own.
Does a clean history mean the vehicle is sound?
No. These are records of things that were reported and recorded. Unreported accident damage, repairs carried out privately, and write-offs from before a register existed or in another jurisdiction will not appear. A clean record is the absence of adverse records, not evidence of absence of history, and we would present it in exactly those terms rather than as a certification.
How reliable is mileage discrepancy detection?
A decrease between consecutive recorded readings is strong evidence of something — though cluster replacement and recording error are legitimate explanations alongside adjustment, and the API describes rather than accuses. Harder is the adjustment that never produces a decrease, where a vehicle simply accumulates implausibly few miles. Plausibility checks catch some of that; they will not catch all of it, and we would not claim they do.
Can the data be shown directly to a consumer?
For some fields in some markets, and it is a specific permission rather than a general one. Write-off register terms in particular often restrict what a consumer may be shown, down to the level of showing a category and date but not the underlying detail. The licence scope is returned per field so your product enforces it at render time rather than relying on someone remembering the rule.
Related blueprints
Vehicle Damage Estimation API
Damage detection, parts identification and a repair cost range from claim photographs, for motor insurers and claims administrators.
Insurance Fraud Detection API
Claim scoring, duplicate evidence detection and network analysis, so organised claim fraud is visible before payment rather than after.
Property Risk Scoring API
Flood, wildfire, storm and subsidence exposure scored at individual address level, for property underwriting and portfolio management.
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.