Home/Offers/Insurance & Claims/Vehicle Damage Estimation API

Insurance & Claims

Vehicle Damage Estimation API

A motor claim starts with photographs taken on a phone in a car park. Everything downstream waits on somebody looking at them.

Motor insurers
Claims administrators
Fleet operators
Accident management firms
Used vehicle platforms

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

The first-notification photographs in a motor claim contain most of what an estimator needs, and they sit in a queue. A straightforward bumper and wing claim that could be settled the same day takes four days because it waits for an engineer to review images, decide whether the vehicle is repairable, and produce a figure. The customer experiences that delay as the claim.

The estimation itself is more structured than it appears. Damage visible on a panel implies a set of parts, and parts imply labour hours from published time guides. Paint operations follow from the panels affected and the finish type. What makes it hard is not the arithmetic but the inference: whether a crease in a door skin means a repair or a replacement, whether a displaced bumper cover implies hidden damage to the crash absorber behind it, and whether photographs taken at that angle in that light can support either conclusion.

The honest position is that photographs support triage and a bounded estimate, not a final settlement figure on anything but the simplest damage. Hidden structural damage is not visible until a bumper comes off. A model that produces a confident single number on a severe impact is overreaching, and the operational value lies in correctly separating the claims that can be settled from the images from those that genuinely need an engineer.

Who buys this

Motor insurers, Claims administrators, Fleet operators, Accident management firms, Used vehicle platforms

Category: Insurance & Claims

What the API returns

What comes back

Detected damage regions with panel identification and damage type per region
Severity classification per panel, from scuff through to deformation requiring replacement
Implied parts list with repair-or-replace recommendation per part
Labour hours derived from published time guides, split by body, paint and mechanical
Repair cost range with explicit confidence, rather than a single point estimate
Total loss likelihood against the vehicle’s pre-accident value
Image quality assessment and a list of the specific additional photographs needed
Hidden damage risk flags where visible damage commonly implies damage that is not visible

Endpoints

Method	Path	Returns
POST	/v1/assessments	Submit claim photographs and vehicle details for assessment
GET	/v1/assessments/{id}	Assessment result with damage, parts and cost range
GET	/v1/assessments/{id}/parts	Implied parts list with repair-or-replace decisions
POST	/v1/assessments/{id}/images	Add further photographs to an existing assessment
POST	/v1/assessments/{id}/review	Record an engineer’s adjudication for calibration
GET	/v1/coverage/vehicles	Which makes, models and years are covered, and to what depth

Request and response

illustrative

Request

{
  "claim_reference": "CLM-2026-884210",
  "vehicle": {
    "vin_last6": "H41220",
    "make": "Volkswagen", "model": "Golf", "year": 2021,
    "pre_accident_value": { "value": 14200.00, "currency": "GBP" }
  },
  "images": [
    { "id": "img_1", "url": "https://\u2026/front_left.jpg", "angle": "front_three_quarter_left" },
    { "id": "img_2", "url": "https://\u2026/wing.jpg", "angle": "left_side" },
    { "id": "img_3", "url": "https://\u2026/bumper_close.jpg", "angle": "detail" }
  ],
  "region": "GB",
  "labour_rate": { "body": 54.00, "paint": 58.00, "currency": "GBP" }
}

Response

{
  "assessment_id": "asm_7712044",
  "status": "complete",
  "damage": [
    { "panel": "front_bumper_cover", "type": "deformation", "severity": "moderate",
      "confidence": 0.93, "decision": "replace" },
    { "panel": "front_wing_left", "type": "crease", "severity": "moderate",
      "confidence": 0.88, "decision": "replace" },
    { "panel": "headlamp_left", "type": "lens_damage", "severity": "minor",
      "confidence": 0.71, "decision": "inspect" }
  ],
  "parts": [
    { "description": "Front bumper cover", "action": "replace", "oem_available": true },
    { "description": "Front wing, left", "action": "replace", "oem_available": true },
    { "description": "Bumper absorber", "action": "inspect",
      "reason": "commonly damaged where bumper cover shows this deformation pattern" }
  ],
  "labour_hours": { "body": 7.4, "paint": 4.1, "mechanical": 0.8 },
  "cost_estimate": {
    "low": 1840.00, "high": 2610.00, "currency": "GBP",
    "confidence": "medium",
    "excludes": ["hidden structural damage behind bumper assembly"]
  },
  "total_loss_likelihood": 0.04,
  "image_quality": { "sufficient": false,
    "missing_views": ["bumper removed or lower front straight-on", "left front wheel arch interior"] },
  "triage": "engineer_review_recommended"
}

Where the data comes from

Your historical claims with final repair invoices	Images paired with the repair actually carried out and the amount finally paid — the only training label that reflects your own settlement reality
Published labour time guides	Licensed repair time data by make, model and operation, which is what converts a parts list into hours
Parts catalogues and pricing	OEM and aftermarket parts data with regional pricing, licensed from a parts data provider
Vehicle identification data	VIN decoding to exact variant, trim and paint finish, since panel construction and paint operations differ within the same model
Vehicle valuation data	Pre-accident values by specification and mileage, needed for any total loss assessment
Engineer adjudications	Your estimators’ corrections to model output, which is the feedback loop that makes the system improve rather than plateau

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

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.

Panel segmentation and damage classification as separate stages, because a model that jumps straight to a cost figure cannot be corrected or audited at the point it went wrong
Vehicle variant identification from VIN before any panel inference, since the same model year can have different panel materials and construction
Repair-or-replace decisions modelled as a classification with its own confidence, as this single decision drives most of the cost variance
Hidden damage risk learned from historical claims where a visible damage pattern was followed by a supplementary payment, which is the measurable form of the problem
Cost ranges rather than point estimates, with the range widening explicitly where image evidence is weak or severity is high
Image quality gating that requests specific missing views instead of producing a low-confidence assessment from inadequate photographs
Triage calibration tuned against your engineers’ adjudications, so the automated/manual boundary is set where your own data says it belongs
Drift monitoring on parts prices, labour rates and model-year coverage, all of which change continuously and silently degrade estimates

What it changes for the business

Faster settlement on simple claims

Claims that can be settled from photographs stop queueing behind claims that genuinely need an engineer.

Engineer capacity

Triage directs estimator time at severe and ambiguous damage rather than at bumper scuffs.

Earlier total loss identification

Recognising a likely total loss at first notification avoids storage, recovery and courtesy car costs that accrue while an estimate is pending.

Consistent estimating

The same damage produces the same parts and hours regardless of which estimator or network the claim lands with.

How it fits into your product

How it embeds

Called at first notification of loss, from your customer app or claims portal, so triage happens before the claim enters a queue
Guided photo capture components that enforce the angles the model needs, which is the single largest determinant of output quality
Asynchronous processing with webhooks, since multi-image assessment takes seconds rather than milliseconds
Engineer review interface showing model output alongside the images, with corrections captured as calibration data
Integration into your estimating platform so the parts and labour lines land in the system your network already uses
Deployment inside your infrastructure where claim images and personal data must not leave 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 20 weeks

Discovery 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

Can this replace our engineers?

No, and we would not build it as though it could. It can settle simple, clearly-evidenced damage without engineer involvement and it can triage everything else accurately. Severe damage, structural impact, disputed liability and anything where the photographs are inadequate still need a person. The value is in the split, not in removing the role.

How accurate is the cost estimate?

Accurate enough to be useful as a range on moderate cosmetic damage; much weaker on severe impacts. We report measured accuracy against your own final repair invoices during the prototype, broken down by severity band, so you can see where it is reliable before deciding where to deploy it. A single accuracy figure across all claim types would hide exactly the information you need.

What about hidden damage?

It cannot be seen in a photograph, so the model does not claim to see it. What it does is flag where visible damage patterns have historically been followed by supplementary payments in your own claims, and exclude hidden damage from the stated range explicitly. Supplementary estimates will still happen; the aim is that they stop being a surprise.

Do the photographs need to be good?

Yes, and this is the main operational constraint. Poor angles, bad light and close-ups with no reference context produce assessments we would not stand behind, which is why the API gates on image quality and asks for specific missing views rather than guessing. Guided capture in your customer app makes more difference to accuracy than any modelling improvement.

Can it detect staged or exaggerated damage?

Partly, and it should not be relied on for that. Damage inconsistent with the reported circumstances, or pre-existing damage with different weathering, is sometimes visible. Deliberate fraud detection is a different problem with different data requirements, and we would scope it separately rather than implying this covers it.

All Insurance & Claims offers →

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.

Discuss This Build Browse All Offers