---
title: "Salvage and damaged vehicle data: fields, sources and pitfalls"
description: "Damaged stock is a different market with a different buyer and no shared damage vocabulary. What the data contains across Copart Germany and Schadeautos, and how to model it without inventing severity."
slug: salvage-damaged-vehicle-data
canonical: https://thecarapi.com/blog/salvage-damaged-vehicle-data
category: Data engineering
author: TheCarApi Engineering
published: 2026-06-03
updated: 2026-08-07
tags: [salvage, damaged vehicles, Copart, Schadeautos]
---

# Salvage and damaged vehicle data: fields, sources and pitfalls

Damaged vehicles are not cheap versions of clean ones. They are a separate market, and treating them as a filter on the main one produces a product nobody in that market can use.

Salvage buyers are repairers, dismantlers and parts operations. They are not looking for a car; they are looking for a specific repair economics calculation to come out positive. That makes almost every assumption baked into a normal vehicle search wrong for them — including the one where price ascending is a useful sort.

This covers what damage data actually looks like across sources, why unifying it into one rich schema fails, and the modelling decisions that make the difference between a usable product and a filter.

## There is no European damage standard

This is the fact that shapes everything else. Unlike the US, where salvage title branding is a regulated, reasonably consistent concept, European damaged-vehicle disclosure varies by country, by platform and by insurer. What you get differs enormously by source:

| Source type | Typical damage disclosure | Usable for |
| --- | --- | --- |
| Salvage specialist (e.g. Schadeautos) | Detailed free text or structured per-area description, often with cause | Repair estimation, parts sourcing |
| Salvage auction (e.g. Copart Germany) | Damage category plus extensive photography, runs/drives indicators | Bidding decisions, triage |
| General wholesale | A boolean, sometimes a short note | Excluding damaged stock from clean searches — little more |
| Remarketing / fleet | Wear-and-tear grading against a contractual standard | Reconditioning cost estimation, not accident damage |

That last row is a distinction worth being pedantic about. Fleet wear grading and accident damage are different concepts that both end up in fields called something like "condition". A car graded down for kerbed alloys and seat wear is not damaged in the sense a salvage buyer means.

## Why unifying damage into one schema fails

The instinct is to design a rich damage schema — affected panels, severity per area, structural yes/no, airbag deployment, water ingress — and map every source onto it. It is the right schema. It is also, in practice, 80% null, because most sources do not publish at that granularity and nothing can conjure the data.

Worse, the nulls are not random. They correlate with source, which means any analysis over the schema is really an analysis of which sources publish detail. That is a subtle enough failure to survive review and reach production.

> **Never synthesise severity from free text** — It is tempting to classify "front end damage, airbags deployed" as structural with a keyword rule. It works on the examples you tested and fails on the edge cases — which are disproportionately the expensive vehicles, where being wrong costs the most. If a source did not state severity, the honest value is unknown.

## The layered model that works

Three tiers, each honest about its own coverage:

1. **A reliable boolean.** `has_technical_damage` or equivalent, populated for every vehicle from every source. Coarse, but it is what the overwhelming majority of users are actually filtering on, and it must never be null.
2. **A severity band where the source supports it** — light / structural / total loss — populated only where stated, explicitly unknown otherwise.
3. **The raw damage payload**, unmodified, for sources that publish detail. Repair estimators read this and ignore the tiers above it entirely.

```bash
# Damaged stock only, across every source that has it
curl -s "https://api.thecarapi.com/api/search?damaged=true&brand=vw\
&year_from=2019&sort=price_low&limit=24" \
  -H "X-API-Key: $API_KEY"

# Full detail on one lot — the raw source damage payload lives here
curl -s "https://api.thecarapi.com/api/auction/schadeautos/1775437" \
  -H "X-API-Key: $API_KEY" | jq '.car_identification'
```

## Photographs are the actual data

For damaged stock this is not a nicety. No text description substitutes for forty photographs of the damage, and buyers make decisions from images in a way they do not for clean cars. Three consequences:

- **Gallery completeness is a quality metric.** A damaged listing with four photos is close to worthless regardless of how good its text is. Consider exposing photo count so users can filter on it.
- **Image durability matters more here.** Post-sale analysis of damaged stock — what did this repair actually cost against what the photos showed — is a core workflow, and it breaks entirely if source URLs expire. [Why an image vault beats hotlinking](/blog/vehicle-image-cdn-api) covers the mechanics.
- **Resolution matters.** Aggressive downscaling that is fine for a clean-car thumbnail grid destroys the detail a repairer is looking for. Keep a large variant.

## Copart Germany, and why the customs point matters

Copart operates salvage auctions internationally, and a lot of English-language material about buying Copart stock is written from a US perspective. For a European buyer that material is actively misleading, because it describes a cross-border import.

German Copart stock is inside the EU customs union. For an EU buyer that means no third-country import duty and no import VAT event — a materially different landed cost from US salvage on the same hammer price. If your product quotes a landed figure, this has to be driven by the source and origin country rather than by one formula.

> **A common and expensive mix-up** — Applying US-salvage import logic to German salvage overstates the cost; applying EU-internal logic to genuinely third-country stock understates it. Both errors reach the customer as a wrong number. See [the calculator endpoints](/docs/calculator) for the per-source fee model.

## What the damaged-stock buyer needs from a search

Design decisions that follow from the buyer being a repairer rather than a driver:

- **Model and year matter more than trim.** Parts compatibility is the constraint, and it is determined by platform and generation.
- **Mileage matters less than usual.** A 180,000 km car with a repairable front end can be a better buy than a 40,000 km one with structural damage.
- **Cheapest first is often the wrong default sort.** The cheapest damaged car is usually the one nobody can economically repair. Sorting by price relative to a clean reference is far more useful.
- **Batch discovery is normal.** Repairers want every repairable Golf VII in a region right now, not one perfect result. Pagination depth and result-set completeness matter more than ranking quality.
- **Runs-and-drives status, where published, is close to a primary filter.** It changes the economics more than most specification fields.

## Modelling recovery value

The question underneath every salvage purchase is: what is this worth once repaired, minus what the repair costs? The first half is tractable from data you can have — a clean-condition reference for the same model, year and mileage band, which is exactly what [comparables](/blog/used-car-market-value-comparables) produce.

The second half is not, and it is worth being clear about that rather than pretending otherwise. Repair cost depends on parts availability, labour rates, hidden damage that photographs do not show, and the buyer's own capabilities. The useful thing a data product can do is supply the clean reference accurately and let the buyer bring their own repair estimate — not to produce a confident number for a variable it cannot observe.

For the wider normalization context around damage fields, see [vehicle data normalization](/blog/vehicle-data-normalization).

## Frequently asked questions

### Is there a standard damage classification for European vehicles?

No. Unlike US salvage title branding, European damaged-vehicle disclosure varies by country, platform and insurer. Salvage specialists publish detailed descriptions, salvage auctions publish categories plus heavy photography, and general wholesale platforms often publish only a boolean. Any unified rich schema will be mostly null, and the nulls will correlate with source.

### How should damaged vehicle data be modelled?

In three layers. A reliable boolean populated for every vehicle from every source, which is what most users filter on. A severity band populated only where the source states it, explicitly unknown otherwise. And the raw source damage payload preserved unmodified, which is what repair estimators actually read.

### Can severity be inferred from a free-text damage description?

It should not be. Keyword rules work on the examples you test and fail on edge cases, which are disproportionately the expensive vehicles where being wrong costs most. If the source did not state severity, the honest value is unknown — a null a user can see is safer than a guess they cannot.

### Does buying Copart Germany salvage incur EU import duty?

German Copart stock sits inside the EU customs union, so for an EU buyer there is no third-country import duty and no import VAT event — unlike US-sourced salvage. Much English-language guidance about Copart is written from a US perspective and does not apply. Landed-cost logic has to branch on the origin country rather than applying one formula.

### Why is price-ascending a bad default sort for damaged stock?

Because the cheapest damaged vehicle is usually the one nobody can economically repair — severe structural damage or a total loss with no viable path back. Salvage buyers are solving for repair margin, so sorting by price relative to a clean-condition reference for the same model surfaces genuinely interesting lots that a raw price sort buries.